|
|
Writing Software is Like Engineering. Ditto.
|
Posted: May 15, 2009 3:10 AM
|
|
> Interesting idea, but as an experienced programmer and
> qualified translator, I would suggest that programming is
> more like translation than creative writing.
I find your analogy better than creative writing, but still not covering how programming really is. IMO, it is effectively a translation of what people want into what a machine can do. But in the process you have to do much more than just translate.
Usually when ppl come to you do write them a program, they are mostly aware of the problem, not of the solution, and if they envision a solution at all it's usually a wrong one. You have to help them build a solution, formulate the solution in some language they can understand, then translate the solution into something that the machine can understand. Translation covers only part of the process.
Some will probably argue that helping the ppl with the problem to define a solution is not actually the programmer's job. IME that's what consultants are paid for, not for the actual programming. And that's what most freelancers do, with more or less success. Therefore, in my world this work is also programming work, even if it doesn't involve writing code.
But if you look at the problem this way, programming starts to look a lot like the initial phase of architecting and engineering a new building. You have an intense communication process with the customer, you make proposals which may or may not be accepted by the customer, you validate accepted proposals on a technical level, and you only have an accepted building plan after all this is over. The main difference between programming and civil engineering is that in civil engineering the big costs happen after this process is finished, whereas in programming the actual building of the product from source code is extremely cheap. Unfortunately, ppl outside IT often think of programming as the process of actually building the building, rather than designing it. A pretty small program, implementing a particular document workflow for an enterprise, for example, has the complexity of a not so small building. But most often customers are not willing to pay as much for the programm and wait as long as they are for the plans for a similarly complex building. Which puts cost and time constraints on programmers which architects and civil engineers don't have. This is all there is, IMO, related to how software development is. However, IMO it is essentially an engineering discipline, which obeys the same rules as any other engineering discipline.
What makes it more attractive for some people than just some engineering is IMO not some fundamental difference, or the fact that you get to do something so much more challenging, but what makes a computer a very interesting toy for most human beings. You get to play with it all the day, and do something similar to what only a fraction of civil or mechanical engineers do: create someting. The people paying you are paying a lot less than if you'd do the same creational work in another domain, but that's OK, since you probably wouldn't be good enough to design skyscrapers or luxury cars or industrial robots anyway. Besides, the customer doesn't mind if you have him paying for mostly the same code over and over again, and just slightly change it, since he can't understand anything of what you do. And also, since you're cheap, compared to your counterparts in other domains, the customer has no problem coming up with new and changed requirements all the time. Which makes the type of quality assurance work performed in other domains impossible.
Then there are some aspects related to return on investment. You create a program, and this program is supposed to earn money for the one paying for it. In case of a building it's very easy to compute the ROI over a period of time, if you rent it out. In case of a mining machine, you can compute the ROI based on how much ore it extracts in a given time period. In case of software, it's much more difficult. Usually software is done to solve a problem, so the ROI could be calculated based on the economies it allows. But the problems most often solved are not easily estimatable in terms of costs. Therefore I'm sure most of the ppl reading this have seen several projects which were halted even if they would have been beneficial, and many other projects which were done only to be dumped some time after finish because the cost of using the resulting software was bigger than the benefits they created. Which probably explains the big project failure rate in software development, when compared to civil engineering or machinery development.
Which reminds me of something: somebody said a long time ago that if civil engineers built houses the way programmers build programs, the first bird to come along would be the end of civilization. Which is a perfectly valid statement, as long as programmers need to do plans for something with only a fraction of the money engineers get for making the plans of something similarly complex. Most of the times, there is no way we can do the same amount of formal validation of our work as other engineers do, with the money we get.
|
|
Previous Topic
