Hey! Jeff, you read my comment and made today’s post from it. Cool.
Prior to changing careers and becoming a full-time programmer, I was a research scientist. We carried out research “projects” which bore even less resemblance to engineering “projects” than do software “projects”. In research, you very oftendon’t even know how you’re going to accomplish task B until you understand the results of task A, which is an investigation of some physical behavior of a new material or the mechanical behavior of a new configuration. Sometimes, if Task A1 gave inconclusive or negative results, you would have to carry out task A2, and maybe A3 and A4, before you knew how task B would or even could proceed.
Yet we had managers who would try to plan the project out to the day, to the dollar. But it is hard to plan in advance for synthesis, for innovation, for invention. You keep trying new things, and studying what went wrong with the last new thing so the next one had a better chance to succeed. Many managers didn’t understand this, so they’d lose patience and interest, and complain about how the researchers never finished anything on time or on budget.
Sound familiar?
Everything depends. If you select a small part to develop, then you can be more certain that if you give some time, the time is enough. And the amount of time allocated depends on what you are doing.
Like you select that one part of an enterprise will be automated, you use this and this technology, those technologies are familiar to you, and you expect no or little business process re-engineering. Automation should be straightforward, maybe some batch processing and an computer-machine interface. You allocate fair amount of time, money, commitment, and skilled experienced motivated familiar people with a good leader. The project goes ok.
Bigger projects has to be divided into smaller pieces. Then it is easier to estimate the time consumption of those smaller pieces.
If you are faced with unfamiliar technology, like you have some unknown hardware, then that is just a real life issue. Its difficult for a project to succeed, if there are unknown hardware or hardware that doesn’t work. So, the solution is to use well documented known hardware that has the reputation of working. When you program some software and blame hardware problems, then its like “I am a good progammer, but we do not have a good hardware person, we just trust luck with hardware”.
And there are many ways to achieve the understanding of a problem. When a customer wants some problem solved, he might not know all related issues about it. And the customer might think that the software or the engineers are the ones who solve the problem, so why the customer has to think something about it. But the customer is needed in analyzing the situation and in providing information. But this can’t either go like only the customer states what will be built, because the customer rarely knows the possibilities and limitations of software engineering.
Well, thanks for using my quote, I hope it made for some interesting discussion. I have to disagree that every project is a leap into the great unknown. All projects I have worked on have 1 thing in common.
Get data from user
Store it
Read data from store
Show data to user
Now, most if not all programs read and store data, so I don’t see how every program is an unproven entity. The methods used to implement the program may be unproven, but the overall concept is not. The fact that the technology changes every 6 months is certainly a problem for this industry.
There are many cases when it is entirely unknown, like writing a new compiler, a new OS, a new piece of hardware. I don’t think the kitchen remodel fits for those situations. These are more R and D projects.
The concept of equating a kitchen remodel to software development I think holds true if the design is not revised.
However, most projects the design is not complete or proven by the time the coding has begun. This leads to a lot of iterative development (as many people have suggested).
Most engineering projects the design and solution are redfined before any implementation, once the design is complete, it is not changed. Try building a 5 lane bridge after you have designed a 2 lane bridge!
With software development the design and solution are refined throughout the implementation.
So, It is much easier to hit a stationary target (other engineering) versus a moving target (software engineering).
We should spend more time on making the target as stationary as possible before coding. This probably isn’t entirely possible, but it is something we should strive for.
Yes, there is like UML-documents, which can be considered as the design. Then the actual program code would be the construct. Each iteration costs when they design and test airplanes with models. Each iteration costs when software design is iterated and program code updated accordingly. But such is life. Though you don’t have to iterate the design, if you catch the change already at the requirements level.
Well maybe pioneering engineering isn’t quite art, but lots of creativity is needed when new things are tried to create. Then others can copy existing design patterns without inventing new wheels.