Ten Software Development Myths Which Are Still Around
Today, I’m going to start with the bottom line: we still have a long way to go.
No, there’s nothing new about it. If you’re a regular reader of this blog, you probably know all about the misconceptions and myths the software industry suffers from. But today wasn’t any ordinary day, because today I had the “pleasure” of hearing so many of these misconceptions packaged together in what might look like a coherent view on software development at first sight.
Discussions about software development in general and quality in particular are part of my daily routine. I don’t know if I’ve heard each and every myth out there, but I think I can safely say I’ve heard most of them. But I have to admit that today I found myself overwhelmed by the volume of myths that split the air is such a short time.
So, as a special service to my faithful readers, here are the top-ten myths and misconceptions I’ve heard just today. If you hear more than five of them together, run (or be prepared for one heck of a discussion).
10. The developer’s task is easy: he should merely translate the design document into code. This is, of course, a one-to-one translation because the design document already deals with any dilemma a developer might come across.
9. Every design decision is documented before it is implemented. Otherwise, how on earth can we expect developers to do nothing but translate the design into code.
8. Reviews are a one-time effort. All you have to do is take an artifact after it is completed, and verify that it is correct. Code reviews, for example, should merely verify that the code is indeed a one-to-one translation of the design.
7. Software development should be like manufacturing. Each of us is a robot in an assembly line. Given a certain input, we should be able to come up automatically with the right output.
6. Software development has nothing to do with creativity. The only part which requires creativity is designing your assembly line. From that point on, everyone should just be obedient.
5. Creativity and discipline cannot live together. Creativity equals chaos.
4. The answer to every challenge we face in the software industry lies in defining a process. That process defines the assembly line without which we are doomed to work in a constant state of chaos.
3. Processes have nothing to do with people. You are merely defining inputs and outputs for different parts of your machine.
2. If a process is not 100% repeatable, it is not a process. Letting people adapt the process and do “whatever they want” is just going back to chaos again.
1. Quality is all about serving the customer. Whatever the customer wants, he should get. Things that don’t concern your customer should not be of interest to you.
As I said, I guess we still have a long way to go…
In one of my next posts I will address each of these myths.
November 11th, 2006 at 1:32 pm
Looks like you pegged it from here.
Yes, these common myths also reveal the fundamental misunderstandings about computers that people have in general. This gave me flashbacks of the management I’ve dealt with in the past. Thanks for the memories - to remind me why I work solo now!
November 11th, 2006 at 5:51 pm
Try calling these as myths to the harressed architect+designer+project manager!
November 11th, 2006 at 6:31 pm
Ditto to Pete. Myths like this are part of why I quit my job. Lidor, I’m looking forward to your rebutting of these myths. To be fair, though, these are probably the top ten big-company myths. Because at least half of these myths don’t occur in small, chaotic companies, they think they don’t have to worry about being decieved by software myths. Maybe I should write my own top-ten list of small-company software development myths. :)
-TimK
November 11th, 2006 at 11:11 pm
Hi Tim and Pete,
You are, of course, right. These myths are indeed symptomatic to a larger company. They just create a different kind of chaos — an implicit chaos — because, as we know, reality is “somewhat” more complex.
Lidor
November 13th, 2006 at 4:49 am
This reads like a management cheat-sheet for a company I worked at for a while. They were starting to off-shore major development projects — since “each of us is a robot in an assembly line”, why not use cheaper robots? Since “every design decision is documented before it is implemented”, we’ll retain smart people in-house to produce those designs, and ship them out. The only acquiescence of the difficulties was that “our processes aren’t up to snuff…so we’ll get CMM certified, and then we should be good.” What a relief, to be able to see it all from the outside…
November 13th, 2006 at 6:04 am
[…] Other Development Ten Software Development Myths Which Are Still Around Ten Additional Software Development Myths Microsoft’s new site for programming hobbyists Software Development Top 30 Mistakes […]
November 13th, 2006 at 5:18 pm
Sounds like you’re just working in the wrong places. If you know better, then leave and let them fail. I haven’t seen such nonsense any place I’ve been willing to take a job in a decade, whether in a big or a small company. Choose better.
November 14th, 2006 at 12:01 am
Anon-e-mouse (catchy name),
Someone once said that every problem in the world could be traced back to some false assumption someone makes.
Thanks for your concern, but who said I work for such a place?
Take care,
Lidor
November 14th, 2006 at 12:04 am
Hey, I just caught myself making a false assumption (After blaming Anon-e-mouse for making one): who said Anon-e-mouse referred his comment to me?
Well, till next time… ;)
November 18th, 2006 at 2:56 pm
[…] Lidor Wyssocky has written about Ten Software Development Myths Which Are Still Around and extented them with Ten Additional Software Development Myths. […]
April 21st, 2007 at 7:01 pm
Neat one …
I have Ten software testing myths here
http://shrinik.blogspot.com/2007/04/ten-software-testing-myths.html
Note that I did not have to touch last 5 myths …
Shrini
February 25th, 2008 at 4:59 am
Hmmm… an effective technology comes with a befitting name. ‘Agile’ as they say it. The long and abrupt, turns and twists in the alley of Software Development process now face the inevitable. Welcome to Agile Software Development methodology. With this, the Software Development process would now hopefully be more structured, less convulsive (for its developers of course!) and markedly disciplined.
March 2nd, 2008 at 11:21 pm
Every business runs with different set of policies to achieve its primary goal. Every different business, most often than not, accompanies different set of inventories and process specific activities to utilize resources in the most specific and effective way. Custom Software Development integrates all these essential differences to come up with a solution that streamlines process specificity with productivity. Taking account of the advancement in software development and eagerness of companies world-wide to participate in a software development process, coming times speaks of positives for SMEs.Hail Custom Software Development. Time is to get customized and be different!
June 26th, 2008 at 6:02 am
hey
Really nice tips!
will try to keep it in my mind
thanks!