What do you do for a living? If you answered "I am a programmer", or , "I am an application designer" or "I am an IT architect" or "I am an engineer" or "I am a tester" I would reply "Me too."
How odd. How can I be all of those things? You are thinking the same thing I suspect. Maybe you do all of the above too - and more? How odd!
Imagine a similar conversation in the road construction industry. I ask "Hello, what do you do?" and you reply "I am the architect, and the designer, oh and I decide on all the materials and um, I build chunks of the road myself and then do all the testing." How distinctly odd that would be.
I have been noodling the whys and wherefores of this. It would be easy to discount the whole thing as a simple consequence of the relative youth of computing. One day, perhaps, building software will be broken down along the same lines as any other industrial scale engineering project. Designers will design and architects will architect and builders will build and it will all be happily, cleanly segmented.
I don't think so. At least not if continue on our current trajectory. Here is how I have tried to explain the core of the problem to myself . . .
Imagine building a road. In the physical world I can pour concrete and put up fences and lay asphalt bit by bit, mile by mile. As long as there is an overall plan in place, it's all good. This mile of road is very much the same as the next mile of road. All we need to do is make sure they are all joined up.
In the software world however, I cannot write functions and create modules and design screens bit by bit, mile-of-code by mile-of-code. Every line, every dialog box every data item, needs to be considered in terms of the overall project. Otherwise, there is no way I will end up with something that scales, that is easily modified, that has 5-nines availability etc. etc. There is an uncomfortably high degree of design smarts and architecture smarts required all the way down to the code cutting itself.
Coding is coding but coding done well is also design and also architecture and also fault tolerance and also testing . . .
How odd.
I think I have a better metaphor. Also from the construction world. Software design is like building a skyscraper. Every bolt, every block needs to be put in place from the bottom up with a view to withstanding load that does not exist yet. Every part is built on every other part. Dependencies exist all the way down to the ground. You cannot just knock down a wall or build on extra rooms as it suits you. You need to wonder what impact every bit of the skyscraper has on every other bit. There are dependencies from top to bottom.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
Esther Schindler
If the comments are ugly, the code is ugly
claird
SVG a graphics format for 21st century
pasmith
Take Chrome OS for a test spin
Sandra Henry-Stocker
Solaris Tip: Have Your Files Changed Since Installation?
jfruh
Android fragments vs. the iPhone monolith
mikelgan
What Gizmodo missed about the Pro WX Wireless USB disk drive
Where Google Chrome security fails: the password
I heard mention that the Chrome OS will have some sort of encryption available a la bitlocker. If it's possible to encrypt personal data using another password or key, then it may have potential for very secure data.... And Ubuntu has an 'encrypt home directory' option, perhaps google should follow suit.
- Dann
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.
Metaphors between
Metaphors between engineering in its traditional forms and software engineering are often used to argue for or against the maturity of the industry. I agree that we don't have the several hundred years of experience that went into the development of civil engineering practices, and even the civil engineers are occasionally defeated by "the user". The recent levee failures in the USA as a result of flooding weren't engineering failures: the flood levels were simply higher than their design could cope with. The user, presumably, decided that the cost of handling a "hundred-year event" flood too high.Given the parallels and your comments however, I'd be interested to know what you think of the extreme programming "do the simplest thing that could possibly work" mantra and the shunning of "big up-front design". Extreme programming is a way of maintaining forward progress, but it's less likely to result in engineering standards. In short, everyone might end up with their own individual railway gauge. What's your opinion?
PS: Your blog's extraction of a title from the front of a comment isn't terribly meaningful, in preview at least.
Steve, My take on extreme
Steve,My take on extreme programming is that it works best when the participants are the sort of multi-talented folk alluded to in the article. Without the vision that comes with concern for the big picture, extreme programming can be high on activity but low on progress.
Progress requires activity but not all activity leads to progress. Re-factoring is a fantastic tool for keeping code clean and validated as the path to progress is traversed but re-factoring activity of itself, does not guarantee progress.
I once saw a worked example of XP where the author said "every time I do this example, it comes out differently".
The non-determinism of that makes me think "art", not science!
In short, I think XP has some great ideas for making multi-talented developers even more productive. However, in this industry, the bottomless pit of need for multi-talented developers is the key bug that needs to be fixed.
regards,
Sean
I do hope skyscrapers aren't
I do hope skyscrapers aren't loosely coupled Sean!