Salon’s Scott Rosenberg explains why even small-scale programming projects can take years to complete, one programmer is often better than two, and the meaning of “Rosenberg’s Law.”
Software is Hard
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Software is an engineering profession, and like most such professions, it’s hard, by the nature of the problem. I mean, when was the last time a new aircraft project for the Air Force came in on time and under budget? Why should software be any different?
I agree 100%, but I’ll add that software engineering is a young discipline when compared to most (if not all) other engineering fields. There are more defined methods and procedures in mechanical engineering, for example, then in software engineering.
Couple this with the fact the universities do a horrible job of preparing students to be software engineers, rather than computer scientists/programmers. You see a lot of hotshots coming out of school who can tell you all about the algorithmic complexity of B+trees, but look all flustered when you ask for functional requirements, a design document, or a test plan.
Here’s some ideas for software engineers to consider: Performance should be in the back of your mind when designing software, but it should not be the most important consideration. Leave performance largely to the hardware folks. Think about scalability, focus on correctness.
For languages that deal directly with memory, use a private interface for dynamic allocation, and build appropriate checks/initialization into these functions. Many mature OSS projects do this, so you might as well reuse a well-tested interface if licensing permits. Same goes for traversing linked lists (which should be circular if possible in order to avoid dereferencing null). Consolidate these code paths so that you limit your surface area. Initialize your variables, and try to do it in unconditional code paths.
Use assertion mechanisms to enforce your pre- and post-conditions where appropriate. You might also want to try the negative-size array trick: if you make assumptions that you can check at compile-time (i.e. assumptions that might break if someone changes a data structure), set a variable to -1 if the assumption is broken or 1 if it is intact, then statically allocate an array of this size. The compiler will barf if you try to allocate an array of a negative size, and you get to catch your bug earlier in the development cycle.
Testing is expensive, too expensive for many OSS projects to do in any formalized manner. That’s why we have static analysis. If you participate in an OSS project that doesn’t use Coverity as a part of its regular quality assurance process, go to their site right now. They offer the world’s best static analysis suite, and they offer free licenses to OSS projects (they charge millions for proprietary projects). There is no excuse for not using this software, and the sophistication of the bugs it uncovers is extremely impressive. Other free static analysis tools exist, such as splint, uno, sparse, and others. They are nowhere near as good as Coverity, but you should throw everything you can at the code.
I hope this helps. It sure beats some rehash of “The Mythical Man-Month” as if this idea was something new.
I agree 100%, but I’ll add that software engineering is a young discipline when compared to most (if not all) other engineering fields. There are more defined methods and procedures in mechanical engineering, for example, then in software engineering.
In addition to not being engineering, software is not that young, relatively thinking. It’s the same age as nuclear engineering, only slightly younger than aeronautical engineering, and older than genetic or biomechanical engineering. It’s older than digital electronic engineering but not nearly as old as electrical engineering.
Software is in a sense quite a bit younger than aeronautical engineering. Planes obviously didn’t exist until the 1900s, but most of the theoretical foundation underlying the field dates back hundreds of years. Much of the necessary mechanics was known by 1750, and most of the necessary thermodynamics and fluid mechanics by 1850. There was some important work on aerodynamics done early in the 1900s. And of course, all that work built on the differential calculus, which was a highly mature field long before the first plane was flown. You can analyze the performance of a basic jet engine, to a high level of accuracy, using only theories that were known 150 years ago.
In contrast, the theoretical underpinnings of computer science are much more recent. Mathematical logic and graph theory date to the mid-1850s, modern number theory to 1800, and the study of algorithms and computation to the early 1900s. None of these fields could be considered mature until at least the last century. This really impacts the maturity of the practical field. Over the last 100 years, the focus in aeronautical engineering has been on refining the engineering, rather than theoretical, aspects of the field. Meanwhile, computer scientists are still coming to grips with the theoretical aspects of their field.
Edited 2007-02-04 03:59
You’re confusing the science of aerodynamics with the engineering of aerodynamics. Engineering disciplines are practical rather than theoretic. Sure, Bernoulli could have analyzed a jet engine, but he couldn’t have designed one.
As far as the theoretic underpinning of computing being recent, ‘algorithm’ itself comes from Arabic. Algorithms have been studied for nearly two thousand years.
Computing is not a science, either, by the way, except in the most pedantic sense (a collection of related knowledge.) At best, it is, as Dykstra proclaimed, a discipline of applied mathematics.
Here is the entire theory of computing, in a nutshell: “The machine does what I tell it to, not what I want it to.” We even tried to fix that, back in the 80s, (CF Lisp “DWIM”) but it’s immutable.
Aerospace engineering does not exist without the science of mechanics, thermodynamics, and fluid dynamics. Engineering is a practical, rather than theoretical profession, but the productivity and effectiveness of the design process is directly related to the sophistication of the theoretical foundation. Thus, when talking about the maturity of the field as a whole, it’s important to consider the maturity of the underlying science. For example, while nuclear engineering is about as recent as software engineering, the former is far more mature, as a result of the fact that it’s based on a mature body of science.
As for algorithms, they’ve been studied for thousands of years, but then again so has mechanics. I was talking about when modern, formal theories arose in the various fields.
PS) The distinction between “applied mathematics” and science is a hard one to make in this case. In physics, there is a pretty direct relationship between the mathematics and the science. Just like register allocation reduces to various solution techniques for the graph coloring problem, structural analysis (and much of aerodynamics and flight dynamics) reduces to various solution techniques for systems of coupled partial differential equations.
Edited 2007-02-04 05:24
For example, while nuclear engineering is about as recent as software engineering, the former is far more mature, as a result of the fact that it’s based on a mature body of science.
Well, there’s no science in software development, but as far as engineering maturity, nuclear engineering is based on quantum mechanics, neither the math nor the science of which date back more than 100 years. Group theory is just as new as formal logic, after all.
IANANE (I am not a nuclear engineer), so I don’t know how much QM you need to know to practice in the field. Does your run of the mill nuclear engineer have to learn the full-blown fancy-math* based modern formulation of QM, or can he get away with the simpler matrix and wave formulations they teach in undergraduate physics?
*) “Fancy-math” is a technical term for math that I never got to in school
“Here is the entire theory of computing, in a nutshell: “The machine does what I tell it to, not what I want it to.””
“On two occasions, I have been asked [by members of Parliament], ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?’ I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question.”
— Charles Babbage (1791-1871)
If it’s about users / customers, don’t forget to read http://www.rinkworks.com/stupid/ – Computer Stupidities – carefully. 🙂
If it’s about users / customers, don’t forget to read http://www.rinkworks.com/stupid/ – Computer Stupidities – carefully. 🙂
I’m going to guess that 99% of the people who read that take away the wrong message.
The vast majority of the questions that people can’t answer about their computers are questions they shouldn’t have to know the answer to in order to use their commputers.
“I’m going to guess that 99% of the people who read that take away the wrong message.”
First of all, please notice the appended “:-)” sign.
“The vast majority of the questions that people can’t answer about their computers are questions they shouldn’t have to know the answer to in order to use their commputers.”
It’s not about questions about a computer. It’s about simple things like how the letter B looks like and if the keys are located on the keyboard or on the screen. Furthermore, if you’re going to use a computer today, you just have to know a few things. Few things, not including e. g. what processor type it has or how much HDD space is free, but a few elemental things, combined with the ability of educated thinking.
Because people like car analogies, here’s an example: Imagine you’re selling cars. A customer walks in and expects you to develop a new car for him. He does not know anything about cars, he even does not know where to drive to. He wants that the car knows by itself. Of course he does not own a driving license… 🙂 So if he wants to drive a car, he needs a license, needs to know how to drive and needs to know about the traffic rules. He does not have to know how many screws are built in the car or from which country the tires are from.
In the foreground, I wanted to quote Ch. Babbage. There are still people around who believe in “thinking software” or even “software that’s making itself”; actually this is a misbelief, which leads to uneducated judgings. It’s hard for software engineers to create software which will be used by customers where the dumbest one is setting the level, and the developers are then blamed for having written dumb software…
It’s hard for software engineers to create software which will be used by customers where the dumbest one is setting the level, and the developers are then blamed for having written dumb software…
That would be hard, and if we ever get to the point where that’s the major issue, I’ll feel sorry for programmers.
But for every dumb customer question you can come up with there’s a ‘poorly designed or implemented software’ story that’s equally as dumb on the part of the programmer.
The first step to fixing the software problem is for programmers to admit that they’re responsible for it.
The first step to fixing it is finding the way the programmers are erroring or the way the customer is erroring. Pointing fingers is the first step to getting nowhere.
Now, if you mean that programmers are the only ones capable of solving the problem then what you’re saying is feasible. However, you might want to rephrase your comment if you want to motivate them to solve the problem
.
“Now, if you mean that programmers are the only ones capable of solving the problem then what you’re saying is feasible. However, you might want to rephrase your comment if you want to motivate them to solve the problem
.
A good idea could be to involve future users into the process of development. I don’t know how often this opportunity is taken, but there is software from which you can tell no possible user has ever been taken into the developer’s views. But there’s a problem: This solution will need at least a minimum of education which you cannot assume for every user. Sadly, but true. Users usually are not interested in the process of development, they’re only interested in the result, i. e. the program that does what they want. This may differ in time (from the moment a customer orders a solution to the moment the solution is availabe for him according to his needs).
As it was mentioned before, there are user errors and developer errors. In some cases, it’s also a combination of both.
So developers should develop software that develops itself by recognizing what the user wants and what he needs. 🙂
Those are some nice tips! If you get a chance, peruse the source code of the MPS: http://www.ravenbrook.com/project/mps/master/code/
It’s a beautifully-written piece of code. It’s in a problem domain where errors can be very difficult to track down, so its very rigorously developed. It’s heavy on comments detailing the assumptions made in each function. Invariants are checked everywhere, and data structures all have guard tags that checked whenever they are used. It’s definitely a cut above most code I’ve seen, and certainly anything I’ve written
Wow you are right thanks for the link!
> Couple this with the fact the universities do a horrible job of preparing students to be software engineers
I agree completely. I would also add that a huge number of software developers never took programming 101.
One of the things that frustrated me, when I did software development, was working with code developed by some self-trained hacker, who knows nothing of structured development.
Usually, when it comes to hiring software developers, the sole criteria is “X years in Y language.” Employers just don’t understand that there is more to developing maintainable software than knowing the programming language.
Often, a degree in math or electrical engineering is considered an acceptable substitute for software engineering. But usually, formal training is not required at all.
Imagine if other engineering disiplines worked like that.
rayiner: The problem with that argument is that it defies the commonly accepted notion that programming is different (and much more difficult) than other fields. I don’t believe programming is that different either. The technical aspects are different for sure, but like you I don’t believe this is where the main problems lie. I think it’s mostly about requirements, feasibility and design. These are things you have to consider no matter the field.
Unfortunately, I get the sense that the computing industry is giving itself an excuse for bad software. Sure, it’s tough. But I believe we can eventually reach good products, even if they are sometimes over budget and overdue.
I’m a big fan of Alan Kay’s stance that a problem with the software industry is that there is a lack of a real “software engineering” discipline. Real engineers have a vast array of tools at their disposal: from proven procedures to theoretical models. The Boeing engineers knew the final performance of the 787, with a high degree of accuracy, before even building a full-scale model, much less a prototype. Programmers often can’t characterize the performance of their systems even after they are built and shipped!
Software biggest problem is the customer, never gets satisfied.
Notice how software for servers and datacentres is generally better than desktop software.
This is because it’s difficult to make software that interfaces with people. You need to understand how the people are going to use the software and people aren’t very good at tell engineers what they want.
Honestly software is a hard thing but there is alot we can do to make the end product what the customer wants/needs and to make it almost bug free.
The main problem with sofware is that business like all things has come up with ‘efficency’ as it`s main purpose and accellerated deadlines tight fisted over bearing catch-phrase spouting penny pinching managers are more likely then anything the main hurdle in development (mainly in large projects).
There is fast, correct and cheap software you can have any two you like (I don`t know who first said this maybe someone can tell me).
You need to read articles before you post. If you’d read you would have seen that he was talking about how software that does something very different and not well defined is really hard where software that’s already defined is usually successful.
In this case the software was being developed in a very unorthodox fashion by someone who wasn’t pinching a single penny. Some of the developers were even full time volunteers.
Howdy
Ok I admit I didn`t read the article first :p
Having now read the article ….
‘I had moved from being a journalist and an editor to being the managing editor of a Web site’.
‘I thought, OK, I don’t know anything about this, I’m a writer and a journalist. I’m ignorant, but let me go educate myself. And so I did, and the first book I read was “The Mythical Man Month” [Frederick Brooks’ classic study of the difficulties inherent in large software projects]. And I quickly realized that our experience was not unique at all. In a way it was the norm.’
Wow ok a ‘manager’ who is 100% clueless in software engineering decides to make a project and it fails horribly, yes hindsight is nice and we can all sit around and pick the bones of how and why but all this is mostly known allready.
This is why you spend a few years at uni get a degree spend 10 more in industry/business and have a notion of what the hell it is all about untill then it`s all academic.
This article is really more of a just another ‘IT’ manager who screwed up royally and has turned it into a book like it was some sort of holy grail.
Really very glad I read the article and my reply was very appropriate aka read the bit about the managers.
I’m about a third of the way through the book (found it in the bookstore a week ago) and it is pretty good. It’s not a great source of accurate technical information or even good project ideas, but it is a relaxing read.
Reading the book made me think “I should try Chandler again, just for fun.” So I downloaded it (I don’t know how it can possibly be so huge). Then I ran it (I don’t know how it can possibly take so long to load). Then I played with it (I don’t know how it can possibly crash so fast).
If they’re doing something amazing they’ve got a long way to go. What they have no appears pretty but is utterly unusable as a calendaring program, but I suppose what’s out now is supposed to be a preview more than anything else so that’s ok.
Anyway, so far I recommend the book.
Compare software projects to Cars, Airplanes, Buildings, Bridges, Chemical Plants – infact most of the industries out there.
The people building those projects often come under the same pressures that programmers do, ie – is there a shortcut to save time (leave out safety checks), buy a cheaper outside component, throw more people at the job even while not increasing money to coordinate them. All the stupid thing done to programmers are done to engineers, construction organizations – but one big difference – programmers give in to the pressure (and there can be a lot of pressure) because they know mostly only the company’s finances will be affected. And engineer/draftsman/construction company probably will not because they know the entire project can collapse kill people (worse killing themselves) if they took all the shortcuts management tried to pressure them with.
Nothing makes it easier to say to the boss than being 300 feet up in the air knowing you were told to leave out some bolts to speed up construction.
Sure about that? I have worked as a software developer at a blood center, a mistake in my code could certainly have killed people.
What about software that is used in air traffic control? Or in medical devices?
Most things are not life and death critical, whether hardware or software. But some things are that critical, whether hardware of software.
Software is hard because of the programmers.
There doesn’t exist another technical vocation which is stacked with more pretenders and incompetents than software development.
No doubt, the ‘Programming for Dummies’ book publishers have made a fortune over the years.
“Software is hard because of the programmers. ”
In this case, you can’t blame the competency level of the programmers themselves, you need to blame the folks who hired them…management.
It’s my opinion that this is the source of software’s biggest headaches: poor project management, poor decision making from the powers that be, etc.
Programmers are a lot like the machines they program…tell them what to do and they’ll do it. Tell them the wrong thing to do, and well, you’ll get the wrong result.
I did not read the article, however I totally disagree with the “1 programmer is better than 2” as I’m a huge fan of agile/XP methodologies which are rapidly proving their worth in IT departments and are becoming mainstream practices. Part of my interviewing process is pairing a candidate with another dev for an hour to work on a project that’s actually in the works.
In a nutshell, blame lies mostly with management IMO.
I agree with your post except for “Programmers are a lot like the machines they program…tell them what to do and they’ll do it. Tell them the wrong thing to do, and well, you’ll get the wrong result.”
In my experience, these are precisely the kinds of programmers that _are_ pretenders/incompetents. Anyone can “learn to program” and then be given a spec and implement it. Truly good programmers will be just as involved in the spec as you are, and will evolve it as they make discoveries during the development process. Good programmers aren’t machines: they’re artists.
But this only applies if your project is actually innovative. If you’re building YAWA (yet another web application) for use internally in some Firm, you may actually be better off with “robotic” rather than “artistic” programmers.
That all depends on the environment. I’ve done consulting work for fortune 500 companies in the past, and we were very much expected to be like robots…granted we were (for the most part) very talented robots as the work was quite difficult, but leeway was a luxury that could not be afforded given the nature of the work being done (mostly systems for large financial institutions).
What amazed me is how seemingly happy a lot of these “robots” were…needless to say, I don’t prefer that type of work, though it does pay well. But by no means were most of these guys incompetent, or pretenders. They just didn’t care about the creative aspect.
Gone are those days for me thankfully. What I truly enjoy about writing code is that it’s one of the few “engineering” disciplines where creativity (if allowed) can be the difference between a successful project and a failed one. It’s a beautiful industry.
I agree.
There is a difference between programming and software design.
For a good project you need people who can see the project as a whole and code monkeys that can write good code.
and it is hard because it demands skills humans don’t tend to have.
I started in this business when ‘software’ was ‘programs’ and we were called, rightfully, ‘programmers.’ Despite upgrading the name from garbage man to sanitation engineer, we still program programs, we don’t “engineer” software. We don’t even “develop” it.
Don Knuth, who to this day is still the best programmer ever, didn’t write “the discipline of software engineering”, he wrote “the art of computer programming”.
I know you and I have been over this before, and that you have more experience in the field, but let me try to make my point again.
Whatever you want to call it, there is a process that should happen before the first lines of code get entered into your editor. It comprises some consideration of the problem, generation of requirements, specification of the interface, design of the data structures and algorithms, and representation of the control logic. These processes might not be so clearly identifiable in many cases, but they happen. Or at least they should.
I call that engineering. If you record this information clearly, a “programmer” should be able to produce the implementation without the engineer’s assistance. The steps outline above represent the “hard” part of “developing” software. That’s basically what the article was about: having a firm understanding of the project is necessary to develop software without confusion and delays.
There is definitely an “art” to whatever it is you want to call the process that results in software. I think the art is in the engineering, and that art and engineering are not mutually exclusive as you seem to imply. The programming part is boring. It’s a technician’s job, easily outsourced to Bangalore or wherever.
I certainly won’t deny that Don Knuth is awesome, but he did turn “goto” into some form of blasphemy. Seriously, it often conceptually represents exactly what you want to do, making your code cleaner and sometimes more efficient. How many times do “programmers” use silly flags and conditionals to avoid using goto?
Anyways, arguing terminology is pedantic, but ignoring the process I call engineering is a big mistake that programmers make.
Whatever you want to call it, there is a process that should happen before the first lines of code get entered into your editor. It comprises some consideration of the problem, generation of requirements, specification of the interface, design of the data structures and algorithms, and representation of the control logic. These processes might not be so clearly identifiable in many cases, but they happen. Or at least they should.
Many disciplines involve planning processes. Planning is not the same as engineering, althogh a certain sort of planning takes place in engineering.
My objection to calling programming “engineering” is that words do matter. People who think that programming is an engineering discipline search the space of solutions to engineering problems to figure out how to make programming better. The answer isn’t there because programming isn’t engineering.
I certainly won’t deny that Don Knuth is awesome, but he did turn “goto” into some form of blasphemy. Seriously, it often conceptually represents exactly what you want to do, making your code cleaner and sometimes more efficient. How many times do “programmers” use silly flags and conditionals to avoid using goto?
You have Knuth and Dykstra confused. Knuth wrote “‘Goto considered harmful’ considered harmful” in which he pointed out that there are valid uses for goto and even explained what they were. It was a response to Dkystra’s paper asserting that goto should be removed from programming languages.
You have Knuth and Dykstra confused. Knuth wrote “‘Goto considered harmful’ considered harmful” in which he pointed out that there are valid uses for goto and even explained what they were. It was a response to Dkystra’s paper asserting that goto should be removed from programming languages.
And you have Knuth and Frank Rubin confused 😉
“‘GOTO Considered Harmful’ Considered Harmful” was by Frank Rubin.
Knuth’s paper on the topic was “Structured Programming with go to Statements.”
Doh!
Thanks for the correction
You have Knuth and Dykstra confused.
Speaking of Dykstra, it is worth considering his views on the subject. Fortunately, he nicely covered this topic in a single paper, EWD648, “‘Why is Software So Expensive?’ An Explanation to the Hardware Designer” (available at http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD648.ht… ).
One of his key points is that good software requires correct theoretical underpinnings as the basis for its design and implementation. Too often software is developed with either no or poorly understood such underpinnings.
Of course, to do this properly, the software developers must have the proper skills and knowledge to identify the theoretical basis and apply it properly. Further, where no such theory exists, the developers must themselves research and develop the theory. This goes far beyond what is currently considered “design”, and is much more open ended and demanding than the work done by the vast majority of engineers in other disciplines.
Whatever you want to call it, there is a process that should happen before the first lines of code get entered into your editor. It comprises some consideration of the problem, generation of requirements, specification of the interface, design of the data structures and algorithms, and representation of the control logic. These processes might not be so clearly identifiable in many cases, but they happen. Or at least they should.
I know exactly what you mean and we even studied these disciplines and let me tell you one thing.. in 99% of the time and situations, this is the biggest waste of time imaginable.
The reason?
Because you’ll end up after hours of careful planning with an implementation block which will require utter redesign.
Been there, done that. I’m programming for 5 years actively now (I know it’s not mastery) and honestly haven’t been in big teams on big projects, but I did try to go this route and it usually backfires in a bad way.
You might say that the planning was poor etc. but especially if you are about to use new stuff (eg: new database, sure it’s just another SQL but different from the one you used before) you WILL stumble on the way in a bad way.
My personal opinion is that a bit of good verbal (unless it’s a huge planning) discussion about the internal logic BETWEEN PROGRAMMERS (no I don’t want to talk about that with customer or marketing, it wouldn’t make sense to them anyhow) is a good thing, but keep it realistic.
Also there should be “tries” of basic stuff before ventures take place. Eg: try out the new DB if it can do all the major stuff first exactly the way we think it can etc. Documentation is never good enough source of capabilities and pitfalls.
I’ve always had a saying that goes something like this:
Writing software will be comparable to engineering when A) 10 different separate product management groups can come up with an identical spec for an application and B) can hand that spec to 10 different development groups and get an identical product back in terms of usability, bugs per LOC, performance, and price.
You do that today, and you’ll get 100 different applications.
In other words, when results are predictable to within the 90th+ percentile in writing software, then it will be an engineering field. Until then, it’s very much an art as Knuth outlines.
Programming is often compared to the construction trades, but that’s not really true. Writing a program is like building a house, except:
(1) You often aren’t given much to go on other than “I need a house.”
(2) You have a choice between using commercial components which ONLY work with their vendor’s tools (e.g. “Craftsman” screwdrivers can only be used on special “Craftsman” screws), or building all the components yourself, from the atom level up. Open Source only looks good by comparison with this state of affairs.
(3) Once the house is built, you can make a million copies of it with the click of a button. Which is why every house anyone would bother building is completely different from any other house that’s ever been built. A lot of your previous experience in building houses will not help you with your current project. You literally have to learn on the job.
To continue the analogy:
(4) When a house is done, it’s done. You don’t make constant changes to an undocumented project.
(5) A house is a physical thing. You can look at it, and see how things work.
(6) Home constuction uses long established standards. The electical outlet in you home would have looked about the same in the 1930s.
(7) Anybody who does anything in the building of a home must be licensed to do so: plumbers, electricians, roofers, etc. Can not be self-trained hacks who do thing their own way.
(4) When a house is done, it’s done. You don’t make constant changes to an undocumented project.
Houses are *never* done. There’s always repainting to be done, roofing to be re-done, mold growing somewhere, etc… They are a perfect example of a “living” project. In fact, one of my absolute favorite houses is my uncle’s which is now more than twice it’s original size, because of all the additions he has done. BTW, this man is not a trained architect OR builder. He is an artist who happens to have the capability of reading up on the building codes and still somehow putting his vision to reality.
(5) A house is a physical thing. You can look at it, and see how things work.
Yes, but a home is comprised of physical and non-physical things. Taken that way, there are definitely some houses that “work” and some that don’t, with no good obvious explanation why.
(6) Home constuction uses long established standards. The electical outlet in you home would have looked about the same in the 1930s.
Have you ever owned a house? They can be a surprisingly painful source of bugs, especially if you get infested with lice, chiggers, or bedbugs… uhh I mean… OK, seriously, aside from insects, houses can have plenty of mechanical problems due to bad design, non-standard implementations, etc… (I am now trying to replace kitchen cabinet doors and bathroom countertops, and finding that no manufacturer makes these sizes, so I have to have them custom-made by a local Mica worker).
(7) Anybody who does anything in the building of a home must be licensed to do so: plumbers, electricians, roofers, etc. Can not be self-trained hacks who do thing their own way.
Bwwahahaha… gasp… sorry… the more you say, the more I realize that software is a *lot* like a house. This analogy’s getting good. Yes, I suppose officially, point 7 is officially correct, for newer housing developments in modern wealthier countries (although you find a lot of hacks even there), but if you take a cross-sampling of houses around the world, you would find an amazing number of hacks and non-standard implementations. Yet somehow, people still manage to live in them. Which is also what people somehow still manage to do with software: live with it.
…
(yes, tongue-in-cheek, but only somewhat)
That’s what she said.
It takes about 15 years of consistent effort to master any reasonably complex skill – whether you’re an athlete, violinist, chef, surgeon, airline pilot or neolithic hunter. Most things are actually reasonably similar in difficulty just different.
Modern teenagers can write software because they are exposed to computers at an early age. In the 1950s programmers often had no exposure to computers until they were PhD candidates. There are no teenage surgeons because no one lets children practice surgery.
There are no teenage surgeons because no one lets children practice surgery.
Oh really? I swear.. sometimes, just sometimes…
I’ve been at it for 45 years and I’m still learning.
– Because most of the times they give, at best, incomplete information about what is needed and how it will be used (already said on early posts);
– Because human interactions is very strong (on most cases) and training is usually relegated as a second cost, at best. That doesn’t happens on most engineering fields, and when they do, they are usually well predict, standardized and the training is reasonably factored (drivers, pilots, operators, …);
– As someone already said, you are not going to see an 15 year old being responsible for critical accomplishment. There are a need to formal education on math and on human interaction. The former must be improved and the last is so ignored on universities that is not even funny;
– And my favourite is: we have very specialized engineers and they don’t tend to work on fields they don’t know very well, that doesn’t happens on software. I don’t know why most of us try to cover all aspects of software development and, when called, accept the responsibility. This leads to big failures for sure. So, we can blame ourselves for a big slice of this pizza.
time after time and again. Just for fun ,, and headaches.
Forgot that. 😉
Edited 2007-02-04 07:51
well, that’s just that and no more. If you compare this with the way opensource is expected to work (note: expected), the opensource model seems by far superior. You buid bricks on top of other bricks. And you add a nice new tool that makes one more thing, albeit a small one.
Around you many experts available at short notice for any brick you would like to optimize.
It gives sort of confidence. But of course, if the end result must be a winning lottery ticket, then, you have to proceed nearly all alone (with your team) and chances are big that you may drown.
His problem is not about method: he clearly would have chosen the most efficient one, opensource. It’s about expected money. It’s just another and more difficult choice, but he is in his own right to try it.
Yeah, what in the beginning was a very focused project changes, at fast pace, on a very disordered chaos, thanks to the “lets add this cool feature” not planned at first, no matter what hack/distortion needs to be done.
Blame us again.
In my experience projects often fail because
– unrealistic schedules / features
– Bad upper management who does not understand software
– Incompetent or lazy programmers, who don’t know what the Right Thing is, or have no grasp of software engineering. I mean you don’t want to touch their code. Ever. Of if you have to, you mentally plan to rewrite it, which anyways you’ll never have the time to do. Some programmers simply don’t care, are just lazy and just happy to have a pay check at the end of the month. Hopefully there is often a few programmers out there who really now what they are doing.
– Bad communication between people.
IMHO the best way to have a project success is to have a team really competent people who go along well and understand each other. That does not always gurantee success but it’s a good start.
This is where Open Source succeed IMO: usually, bad code is not allowed to be committed.
I thought, OK, I don’t know anything about this, I’m a writer and a journalist. I’m ignorant, but let me go educate myself…
Amateur hour, go figure, this aint rocket science dammit, it’s brain surgery. His project failed before it even got out of the chute, “Moonshots”, never work, rather your project plan be made up of lots of little successful ones. Super Bowl Sunday here so I’ll go with the Vince Lombardi method, “It’s a game of inches.”.
No it’s an interessting book, (bought it and read it)
It gives an insight in software development, the Chandler team are all proffesionals who have been there done that before. Problem seems to be the vision of the project, it’s a bit too vague and they waste to much time designing and talking and go anal over a couple of buttons.
But they are not the only software project team that’s running late.
Edited 2007-02-04 18:34
Software Engineering is a term that’s not even an oxymoron, it totally meaningless. Programming is not engineering, and has about as much relationship to engineering as a garbage hauler, aka sanitary engineer. Software development as it is today does not even rate the term ‘professional’. Hacks, gifted in many instances, but hacks all the same.
As long as programmers, software developers, authors, coders, hackers, and software companies refuse to accept liability and responsibility for their applications, software will continue to be unstable, unreliable, untrustworthy, and in general trashy. When the programmers actually adhere to a code of ethics equivalent to a PE, and accept personal, professional, and financial liability for the performance of their product, then perhaps a true software engineering profession can develop. Until then, programmers aren’t software engineers, and are only professionals in the sense of a paid gigolo.
I’ve seen a lot of valuable insights from a lot of people here who have been contributing on this discussion.
A related question I’m having is what should be “the best” mix of roles in a ” typical” software project:
User–Coder
User–Analyst–Coder
User–Analyst–Design–Coder
User–Analyst–Architect–Design–Coder
My company’s idea (financial services)
User-AccountManager-Analyst-Architect-Design–Coder
The reason I’m asking this is because all these models above have their pro’s and con’s, but I can’t seem to find evidence or research which clearly shows the superiority of one of these models against the other(s).
I also know that you could combine some of these roles in one person.
The reason I’m asking this is because all these models above have their pro’s and con’s, but I can’t seem to find evidence or research which clearly shows the superiority of one of these models against the other(s).
You won’t find the research because there’s no single method that’s well suited for all problems.
It’s not even clear that a single method is well suited to a particular piece of software over its lifetime and what little research there is suggests otherwise.
What’s surprising (actually it’s really not surprising seeing as too many teams don’t put enough emphasis on this) is that in all of your role descriptions, you’re missing what is probably THE most important role:
Tester.
The only 3 you must have are User-Developer-Tester…sure, the coder can also be the tester, but most studies have shown better results if the tester is a separate entity. So IMO the minimum is 3 entities, but the sky’s the limit as far as how many actual roles there can be.
One large project I worked on was Users-Project Managers-Business Analysts-Business Stakeholders (AKA management)-UI Designers-Architects-Infrastructure (AKA sys admins)-Coders-QA-Deployment Team-ad nauseam.
Never leave out QA/Testers though.
I’ve met quite a few people in my short 14 years of coding who have said the following:
“I was a programmer for a while, but I got (bored/sick/tired/confused) with it. Now I’m an (accountant/realtor/etc..)”
And what I’ve realized is – ‘Computer guys’ use computers, programmers program. Whether you taught yourself (as most of us did), or learned in some class (which is often the worst way to go) – most good programmers like to think in terms of code, not cash. All the people who enter the software industry (I mortally despise the term ‘I.T.’) so they can be the next ‘Bill Gates’ need a philosophical brick to the face. Bill Gates was not (and should never be considered) a great or revolutionary programmer – he was just a very fortunate businessman. And this is the question:
“Why do you program computers?”
A: Because. Just, because.
If you just want to get rich quick – your better off in real estate. There are personalities that simply can’t handle software development – and when they try, they fail (not to be mean, it just happens).
It’s not so much a matter of being an ‘Einstein’, it’s more like a ‘Ghandi’. Programming is not pure math (you don’t need to pass calculus to say “Hello world!”), but you need an endless supply of patience, curiosity, and forgiveness (to forgive yourself for your mistakes). Without these, it will be an unpleasant process to grasp any computer language.
As for me, I think I’ve got lots of technical curiosity, I’ve had to forgive myself many times, and I’m still working on my patience.
Edited 2007-02-05 01:00
1: the problem domain is infinite, where as in other fields it is not.
2: mainstream programming languages are bad.