In this post, I would like to visualize some bad design and coding using some real life parallels.
But first a disclaimer: as bad as many of the following examples look like, sometimes compromises need to be made - to meet a short-term deadline, to save cost in the short-term, due to temporary lack of expertise, making some feature work for a customer on the spot, etc.
As long as you acknowledge in advance that what you did is not the right way to do it, and are willing to improve and proceed to apply the proper solution...
First, let's take a look at the equivalent of some messy code.
 |
| Source: http://bit.ly/jmL7RC |
 |
| Source: http://bit.ly/kiWmRV |
When one of the power lines dysfunctions, how long do you think it would take to fix it ? Or just to find it ?
Same is with bugs in code that looks like this...
Now, how about using a workaround solution rather than upgrading the infrastructure to handle it properly ?
 |
| Source: http://bit.ly/myfL5v |
Sometimes, just because you can make two pieces of software work together doesn't mean you should:
| Source: http://bit.ly/lpx3vE |
Here is how it looks like when you apply a patch rather than rewriting a broken piece of code:
 |
| Source: http://bit.ly/iYIyAa |
And finally, this how is it looks like when you leave some useless code around:
| Source: http://bit.ly/jfFKqE |
For contrast, here is the probable visualization of a good piece of software - fast, sleek, great design, and it gets you to where you want to go to:
| Source: http://bit.ly/jpZAGU |
Do you have any more similar design or code visualizations ?
That last picture is gold plating - you don't need that necessarily!
ReplyDeletePerhaps it is gold plating, but don't you ever wish to drive one ? :)
ReplyDeleteI would be happy to hear suggestions for other alternatives... (iPhone was a first idea, but that would have turned into a long discussion as well...)
Iphone would be bad yes :P
ReplyDeleteOne could argue about a Toyota Prius, but I guess there's something to say about Toyota's nowadays as well.
Some time ago, I used forks to illustrate the quality/cost trade-off in software (including gold plating, quite literally :-)
ReplyDeletehttp://www.carlopescio.com/2011/01/can-we-really-control-qualitycost-trade.html
The last picture has a problem: The customer wanted a vehicle to transport lots of stuff or people in a comfortable way...
ReplyDeleteI agree, perhaps the last example was not the best one. Please note that it was only a minor point in the discussion, by no means the main subject - it was supposed to be just a contrast to the other 5 examples of poor code/design. I hope that this main message did get through...
ReplyDeleteThanks for inspiration, I'm definitely gonna use something similar in my company internal presentation about software development!
ReplyDeleteSo, you show a few pragmatic affordable solution and one totally that is not pragmatic at all and wildly expensive. The pragmatic one seems like the one I should buy 9 times out of 10.
ReplyDeleteThe first solutions were created by people and businesses that are in business and making a living respectively. The last was created by a struggling business for people with too much money.
Your argument leads to the conclusion that only in rare situations one should invest in perfection, while I think there are better arguments that would convince business owners that in the case of software it is better to err on the side of quality, because it is not wildly expensive and rather pragmatic too.
The analogy is cute, but not very helpful in my opinion. Remember that people still compare software with cars are usually those that outsource to an offshore factory..
It does get trough, those are great examples. I'll forward it to my co-workers :)
ReplyDeleteI think it is a good picture for what to aim at because if you do, then you may land at something that is good enough and that will solve your problem. But it is true, no one needs a car like that. Good article.
ReplyDeleteNice way! :)
ReplyDeleteI think the majority of people who commented missed the point of this article. It was an excellent and innovative way of getting your point across, one I personally wouldn't have thought of. Credit where credit is due rather than highlighting one point they felt deserved critiquing.
ReplyDeleteRecently I've read a very good related post:
ReplyDeletehttp://www.codinghorror.com/blog/2007/11/the-big-ball-of-mud-and-other-architectural-disasters.html
Good pictures, including the last - I'm somehwat confused that so many people complain about the car. It is clearly an image of good design, no? Whether it is gold-plated or feature-overloaded depends on who you built it for? These type of cars do have customers that want precisely these features, and pay well for them, even if they don't need them. On the other hand, I doubt there are any customers that truly desire any of the solutions in the other pictures.
ReplyDeleteGood job, nice pictures!