Jens Schauder says that perception that the software development field is immature is fine, but ignorant of how software development works - that the crucial issue isn't maturity, but bugs.

As far as ignorance, he throws out these points:

• Reuse in software development is extremely high, "as if workers in a factory would just use a different paint and maybe a different brush to change the resulting product from an ipod to a car."
• Automation is extremely high.

What he says is more important:

...let us tackle the real challenges of software development: When every pixel the designer (i.e. coder) changes results in completely different behavior of the product, and when this product is delivered to the customer within days, often hours, there is a high risk of shipping bugs.

We don’t need more automation. We don’t need more reuse. We need better strategies for preventing and finding bugs. I take the automation and reuse any time, but the important stuff are the bugs.

The problem is not so much a lack of good practices, tools, and automation. The real problem is all those software developers coming onto the market with essentially no experience or training using any of these practices, tools, and automation and setting back the clock forty years or so by doing waterfall style development, not doing TDD, spending too much time fussing over requirements that don't accurately reflect what is really needed, and reinventing the wheel in terms of processes, tools, and practices. That combined with cost savings and out sourcing to cheap contractor companies means a lot of low quality software gets written by developers that lack the necessary skills to their job properly.

The traditional way of turning a newby software engineer into an experienced one is through apprentice ships. They learn by observing others. The problem is that that requires something that is often missing: competent developers to observe. Without peers and without training there is very little hope for a wannabe junior software engineer to become good at his/her job.

Bugs are the symptom of that.

I agree: there is a lack of experience and of competent developers from which to learn in many jobs.

However, let's not forget that extremely competent developers also create embarrassing bugs. Quality control and testing are key even if you have experienced developers.

During the development stage of a software product, a lot of things happen and for those things there's got to be a way of dealing it, I mean you need to know what to do in order to avoid the creation of other bugs than there are at the current development time. Now these specs should be known by every developer that works on that project and also that developer should know the degree of freedom that he has.

This thing can be done in 2 ways:

1. You take the developer through a tour in which he accustoms with the workflow and learn his way around.

2.Write a specification a so called protocol(what the developer cand do, and what he can not do) and the developer should read it thoroughly before he actual starts developing.It can be combined with 1 by all means.

Then, after knowing his way the devloper starts to code and reuse the code that was written before. Still this approach isn't 100% solid because the human factor is in the middle and by that I mean that mistakes can be done by all persons who are implied in the project even by those who have a large experience in the field. A wierd architecture of the app, or ambigous requirements for the developer are enough, to enable some bugs, that shouldn't arise in the first place.

Bugs are the main result of how much the degree of freedom the developer has, combined with weak architecture .

 

Tests cases might be good but often, not needed. The most needed is responsibility toward the client. Problem is developers often completely forget who is the client and also do never formally deliver anything in a way that encourages commitment.

Tight specs all the way, requirements and technical. As a developer, don't let me choose how a part of the system should behave, tell me. Never let me come up with my own requirements - they'll have nothing to do with what the customer wants, be overly complicated, and wont be in a spec either so no one will know whats going on except that 1 person who implemented it.

Developers wear the developer hat and when reading specs should look for what's missing, what's problematic and need to spend their quality time on design, review and coverage and integration. Bugs caused by misreading a spec are easy to make and fortunately (should be) easy to solve. My own benchmark is that a bug should be able to be fixed within 1/2 hour, or at least its cause identified and a possible solution known. If it takes longer than that then either the developer needs help, or that part of the system needs help and a rewrite.

Having the right culture, and the right people in the right places will go a long way to having the processes and structure that can deal with problem areas.

Agree that even experienced developers also make mistakes and create bugs. This is normal as we are human not machine. However, experienced developers make used of good practices, appropriate design patterns to make themselves easy to debug and even adhoc changes. That's why experienced developers are able to fix bug within a 1/2 hours or even more less time. I do not agree with the author saying about bugs are more important than an "immature field" at the developer's perspective. To me, these 2 things come together. A cleaner and readable code will help you to spot bug easily. Let me emphasize again. Developers are human and we are emotional. Don't you feel frustration when doing a lot of copy and paste work? You will actually found that working in a frustration mode create more careless mistake(at least it works on me! LOL!!) Secondly, I want to emphasize that spotting bugs and ensure the quality of the software are the jobs of tester. As a developer, I appreciate and respect good tester and we work together to make system work fine. Lastly, as a project manager perspective, bugs are more important than an "immature field" ^_^ Just my 2 cents.