 |
Software is created in a realm of intangibility. This necessary but foreign situation has given rise to common myths; some go against intuition and some stem from older technology or a misunderstanding. Let’s debunk the top 10 software myths! |
1. Adding developers to a late project will get the project back on schedule. |
|
|---|---|
 |
This is a very common and intuitive response to a schedule slip in a project. Surprisingly after additional manpower is added the project actually slips later. Brooks’ Law is often cited to refute the common myth; stating ‘adding manpower to a late software project makes it later’ (Fred Brooks – The Mythical Man-Month). While an oversimplification, it is a good rule of thumb. The counter-intuitive result of a later project is due to the increase in necessary communication between the team; which increases exponentially as additional people are added to a team. |
2. All developers are equal or at least interchangeable.
|
|
|---|---|
 |
As much as many people wish this was true; it is simply not the case. Each developer has a specific skills and traits that can combine for a great team; but are rarely found in the same quantities per person. The strongest teams are formed when this individuality is considered and leveraged. Projects suited for the team will go smoothly and new people added to the team can be selected to fill any missing skill gaps. |
3. The more people who have seen the code; the fewer bugs there are.
|
|
|---|---|
 |
This myth stems from the open-source world of software development; implying that open-source has an advantage over proprietary software simply because anyone can review code, fix bugs, and add features. Just because anyone can; does not mean anyone does. Fred Brooks (from the 1st Myth!) was aware of this myth as well, stating ‘The fundamental problem with program maintenance is that fixing a defect has a substantial (20 – 50 percent) change of introducing another [defect]’. A study in 2009 noted that a small focused team is preferable to many separate developers when fixing bugs. The smaller team was able to fix bugs with a smaller number of newly introduced issues; prompting the old adage that ‘Too many cooks spoil the broth’ holds true in software as well. |
4. Change is easily accommodated, since software is flexible.
|
|
|---|---|
 |
The intangibility of software development helps add to this myth. Simply because something can be changed or updated during development does not imply that it will have a small or no effect. This actually holds true even if development has not started on that feature yet. The architecture and flow of the software could be impacted by the change and need to be changed; which in turn can have a domino effect on the rest of the system. Generally getting complete requirements or known of changes as early in the development process will cost substantially less than late in the project. |
5. General description of the objectives is enough to begin creating programs. Details can be added in later.
|
|
|---|---|
 |
Similar to myth 4 this stems around changing requirements and initial direction. Ambiguous requirements or broad goals can prompt development progress and design in unnecessary or even incorrect directions. While the exact details may not be available before development begins; having a clear vision and goal will immensely help in ensuring early work is not replaced later in the project. |
6. Writing software may be creating; but it is not creative
|
|
|---|---|
 |
I don’t think anyone would argue that writing software is creating something; but many people do not agree that it is a creative process. This myth is easily debunked as you examine the steps and processes different developers take to solve a problem. A great developer will make leaps and introduce new ideas that bring simplicity and avoid potential pitfalls. These creative solutions result in a smaller more manageable code base and can positively impact the delivery dates and reliability of the resulting system. |
7. The project is completed when the code is delivered.
|
|
|---|---|
 |
Studies have shown that between 50 and 70 percent of efforts are expected after the initial software is delivered to the users. This myth also prompts the question on when is software finished. I am reminded of the old adage by Paul Valery, ‘An artist never really finishes his work; he merely abandons it’. This applies very directly to software; as maintenance and new features can cause it to evolve into something different and hopefully much greater than originally built. |
8. Cutting Edge tools produce better results.
|
|
|---|---|
 |
It is very inciting to believe that if we just used this new language or new tool we can see substantial performance increases, quicker development, and fewer bugs. Unfortunately this is historically not true; in fact the opposite is shown in many cases. For instance Twitter was built with the hot Ruby on Rails stack but ended up migrating code sections to Java; Reddit switched from Lisp to Python, and Yahoo Store converted from Scala to C++ and Perl. To quote Fred Brooks (again!) ‘There is no single development, in either technology or management technique, that promises even one order of magnitude improvement in productively, in reliability, in simplicity’ (From No Silver Bullet). |
9. Documentation is unnecessary and will slow things down.
|
|
|---|---|
 |
I think most every developer is guilty of not documenting enough in response to a hard deadline or emergency response. There is a long term cost to ignoring documentation though, new team members do not have a common location to reference for project information and the reason for decisions made can get lost. This is dangerous as the project continues, as the team can slip into a cycle. George Santayana said it best, ‘Those who cannot remember the past are condemned to repeat it’. |
10. Learning a programming language is just like learning a foreign language.
|
|
|---|---|
 |
They both have language; it must be about the same. While the first programming language you learn will take some time, but that time is mostly spent learning programming techniques and design patterns rather than the specific language itself. These techniques and patterns can be leveraged across many different languages; making learning the second programming language much easier than the first. Generally an experienced developer can learn a language from the same paradigm in about two weeks. |
Interesting post! Always good to see people quoting Brooks.
Cool new format!
Great List; I could easily add 5 more. Have you considered writing on technical debt?
Documentation is like flossing; everyone knows we need to do it but no one wants to!
I had no idea the amount of time spent after a project is completed. Makes sense if you take a minute and look backwards though.