I’ve mentioned on this blog a great article i found almost exactly four years ago. It’s about frequently forgotten fundamental facts in software engineering. I will have to revisit this article because it seems that those facts are still valid today.
And it seems that people tend to forgot them. So i will quote them again just as a reminder.
P2. Good programmers are up to 30 times better than mediocre programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field.
Let’s discuss this. Did you ever had this experience ? Because i had. I worked with good programmers and bad programmers. Good programmers tend to find solutions and have a good productivity overall. Bad or mediocre programmers not only have a bad productivity but they will also slow down everyone in the team with their constant problems and incapacity to adapt to new working conditions.
T1. Most software tool and technique improvements account for about a 5- to 30-percent increase in productivity and quality. But at one time or another, most of these improvements have been claimed by someone to have "order of magnitude" (factor of 10) benefits. Hype is the plague on the house of software.
This is one of the fundamental facts. How many times we encountered this ? When someone says that something will save the world. And in fact you get to the point where not only that this tool doesn’t save the world but it introduces more problems then it solves. And this seems to be true even in TYPO3 where i have the impression that the developers are always chasing what’s currently the biggest hype. Then they abandon it and chase the next hype.
EF1. Efficiency is more often a matter of good design than of good coding. So, if a project requires efficiency, efficiency must be considered early in the life cycle.
Well, sometimes customers rush in and want to start a project right away and some of them don’t understand the need of proper planning and design. Without planning, specification and technical design the project will suffer on the long term from lots of flaws, efficiency is one of them.
RD1. One of the two most common causes of runaway projects is unstable requirements.
ES1. One of the two most common causes of runaway projects is optimistic estimation.
These two together can be a deadly combination. Even one alone is enough to wreck havoc in a project. So handling these two from the beginning of the project is a must in order to be successful with that project.
ES2. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that this occurs before the requirements phase and thus before the problem is understood. Estimation therefore usually occurs at the wrong time.
ES3. Most software estimates are made, according to several researchers, by either upper management or marketing, not by the people who will build the software or by their managers. Therefore, the wrong people are doing estimation.
ES4. Software estimates are rarely adjusted as the project proceeds. So, those estimates done at the wrong time by the wrong people are usually not corrected.
ES5. Because estimates are so faulty, there is little reason to be concerned when software projects do not meet cost or schedule targets. But everyone is concerned anyway!
ES6. In one study of a project that failed to meet its estimates, the management saw the project as a failure, but the technical participants saw it as the most successful project they had ever worked on! This illustrates the disconnect regarding the role of estimation, and project success, between management and technologists. Given the previous facts, that is hardly surprising.
ES7. Pressure to achieve estimation targets is common and tends to cause programmers to skip good software process. This constitutes an absurd result done for an absurd reason.
These should be written with bold letters on the walls of every software company.
Laszlo Bodor
