The Real World doesn't have Undo
Posted on:April 15 2015
Software projects are quite often compared to other scenarios, like building a house or a car. I've often heard the claim that time estimates, planning or defect management are so much better in those other areas of engineering. But they are not true, in my opinion.
How many programmers do you know, who ever did some "real world engineering"? If you are a software developer, have you ever built something with your own hands? During the last 5 years, I've build a lot of stuff which was not software, and I can recommend to try it out: It is different to the process of building software, but you learn a lot which you can also re-use for your programming skills, interestingly.
For example, during the last 2 or 3 weekends, I build this thing here:
It is just a simple wall, a walk-in closet. But it is complex enough, and you need a bit of planning for it. When I built something like
this the first time, and did something wrongly, I thought "Damn! There is no Undo button". There is also no copy and paste or version control
system, so you need to do that project a little bit more differently than a software project.
But there are also a lot of similarities: Time and resource estimates are nearly always completely wrong. In the beginning usually by a
factor 2, by my experience. But it gets better. It also doesn't matter if you are doing the project or parts of it yourself or are
outsourcing it. It will usually take longer. And more money then anticipated. Also, there will be bugs. And the way they are fixed will
not always be the correct one.
Basically, things I learned from building "real world stuff" is that planning and re-using is much more important than for software. Also, I think the way I am doing software projects has been improved quite a bit since I started building stuff like this. It is also a nice way to 'relax' from a thinking intensive programming session. So I can really recommend trying to do some DIY projects from time to time.
How many programmers do you know, who ever did some "real world engineering"? If you are a software developer, have you ever built something with your own hands? During the last 5 years, I've build a lot of stuff which was not software, and I can recommend to try it out: It is different to the process of building software, but you learn a lot which you can also re-use for your programming skills, interestingly.
For example, during the last 2 or 3 weekends, I build this thing here:
It is just a simple wall, a walk-in closet. But it is complex enough, and you need a bit of planning for it. When I built something like
this the first time, and did something wrongly, I thought "Damn! There is no Undo button". There is also no copy and paste or version control
system, so you need to do that project a little bit more differently than a software project.
But there are also a lot of similarities: Time and resource estimates are nearly always completely wrong. In the beginning usually by a
factor 2, by my experience. But it gets better. It also doesn't matter if you are doing the project or parts of it yourself or are
outsourcing it. It will usually take longer. And more money then anticipated. Also, there will be bugs. And the way they are fixed will
not always be the correct one.
Basically, things I learned from building "real world stuff" is that planning and re-using is much more important than for software. Also, I think the way I am doing software projects has been improved quite a bit since I started building stuff like this. It is also a nice way to 'relax' from a thinking intensive programming session. So I can really recommend trying to do some DIY projects from time to time.
Comments:
I reject your suggestion that construction (or cooking, live performance of music, standup comedy, drama or athletic sports) are best done using the waterfall methodology.
A. Gile
Quote2015-04-15 13:51:00
Hm, did I suggest that anywhere?
niko
Quote2015-04-15 15:29:00
Nicely done wall, btw.!
I personally think that software projects generally involve much more unknowns than e.g. construction projects. When you are a dry-wall builder after some time you will rarely encounter a dry-wall problem you didn't solve once already. This compares to implementing, say, a sorting algorithm for the tenth time, you wouldn't get that all that wrong either. But you usually don't do that, because you can reuse the one you (or someone else) already wrote. This doesn't work all that well for a dry-wall, as someone else is likely going to miss his... Challenge an architect/structural engineer with "build me a tower which is a mile high", this is somewhat closer to many software projects. Except that likely the "mile" is not all that clear in the beginning, and it may end up to be a mile long instead of tall, and being a paved road, but still using parts of the solution for the initial "mile high", since noone wants to spend additional money on having the structural engineer redo his calculations, which may affect interior design in unforeseeable ways.
And, true story, construction projects do not go as smoothly once scale grows, like the 300m wall built ... in the wrong place. So it had to be torn down again. Costs a bit more, though, as with software.
I personally think that software projects generally involve much more unknowns than e.g. construction projects. When you are a dry-wall builder after some time you will rarely encounter a dry-wall problem you didn't solve once already. This compares to implementing, say, a sorting algorithm for the tenth time, you wouldn't get that all that wrong either. But you usually don't do that, because you can reuse the one you (or someone else) already wrote. This doesn't work all that well for a dry-wall, as someone else is likely going to miss his... Challenge an architect/structural engineer with "build me a tower which is a mile high", this is somewhat closer to many software projects. Except that likely the "mile" is not all that clear in the beginning, and it may end up to be a mile long instead of tall, and being a paved road, but still using parts of the solution for the initial "mile high", since noone wants to spend additional money on having the structural engineer redo his calculations, which may affect interior design in unforeseeable ways.
And, true story, construction projects do not go as smoothly once scale grows, like the 300m wall built ... in the wrong place. So it had to be torn down again. Costs a bit more, though, as with software.
xaos
Quote2015-04-16 10:36:00
Whoa, that part about that 300m wall doesn't sound nice at all!
niko
Quote2015-04-22 06:19:00
Add comment:
|
|
Possible Codes
| Feature | Code |
| Link | [url] www.example.com [/url] |
| Bold | [b]bold text[/b] |
| Quote | [quote]quoted text[/quote] |
| Code | [code]source code[/code] |
Emoticons
 |  |  |  |  |  |  |  |
 |  |  |  |  |