转载：7 Reasons Why Software Development Is So Hard

读后小记：从多个反映了当前软件开发领域面临的现实问题，说明软件开发是一个复杂的、充满诸多不可预知因素的过程。反映了当前影响软件质量的多种因素，证明了软件过程不是个体活动，而是关系诸多人、诸多方面的复合工程。软件的质量掌握在这方方面的的干系人手中，不是某一个人能够决定软件质量，因此需要真正意义上的大QA，全面质量管理。

 

原文参见：http://www.finextra.com/community/fullblog.aspx?blogid=6836

Introduction

I’m often asked by lay people whywe humans can undertake large construction or engineering projectswith relative success and yet we struggle to deliver softwareprojects without bugs and on time.

In an attempt to explain why thisis the case I give below 7 reasons why software development is verydifficult. This is not an attempt to condone shoddy softwaredevelopment practices. Rather, I’m trying to show that even withexcellent development processes it is still difficult to dosoftware development right.

1. The software industryis young

Humans have beenbuilding house, roads and bridges for thousands of years.We’ve no idea how many house or bridges collapsed in the early daysas humans learned the correct techniques for building thesestructures.

One has only to look at theinfamous Tahoma Narrows bridge collapse in 1940 to realise that,thousands of years after the first bridges were built, they stillhadn’t perfected bridge building.

In comparison the softwareindustry is only about 50 years old. We still have a long way to gobefore we have the body of experience behind us that theconstruction and manufacturing industries have.

Today the construction industryuse mostly prefabricated materials and parts. Most of these aremade by machine and have been tried and tested on many otherprojects.

The software industry on the otherhand doesn’t have the range of pre-built components that otherindustries have. Software systems are fundamentally built by aprocess of discovery, invention, and creation of new componentswith the result that each new system is a custom project createdfrom scratch. This leads us to our next point.

2. Every line of code is apotential point of failure

Because all new projects arecustom built it follows that every line of code is unproven andtherefore should be tested. However, in the real world, this istotally impractical.

Each line of code will havedozens, even thousands, of possible inputs, outputs, states ordependencies to deal with. It can impact, or be impacted by, otherlines of code or by external factors. Even if it was possible todocument every test case for a line of code you still couldn’t besure that there wasn’t some unknown factor that could cause anerror.

And testing a single line of codeis only part of the challenge. No line of code exists on its own.It is part of the whole system and the whole needs to be tested toensure that all parts of the application functioncorrectly.

The sheer complexity of softwaremeans it is impossible to test every path so in the real world thebest project teams will implement processes that are designed toincrease the likelihood of the software being defect free. Theywill use techniques such as coding standards, unit testing, smoketesting, automated regression testing, design and code reviews etc.all of which should improve the quality of the software.

All of this testing comes at acost. The question to be answered on every project is – howcritical is this software and how much testing should we do toensure the software is correct?

Too often the testing phase isrushed and the software goes out with an unacceptable level ofdefects. On the other hand, for most systems there are diminishingreturns for extending the testing past a certain point. There comesa point with all software where the value of getting the softwarereleased is greater than the value gained by continuing to test fordefects. This is why most commercial software gets released eventhough it is known to contain defects.

3. Lack of userinput

For over 10 years the researchcompany, The Standish Group, have surveyed companies about their ITprojects. The No. 1 factor that caused software projects to becomechallenged was "Lack of User Input".

Reasons for this caninclude:

• The system is being promoted bythe management and so the business users have no buy-in
• The users are too busy and have“more important” things to do
• Relations between the usercommunity and the I.T. team are poor

Without the involvement and inputof a user representative the project is doomed to failure. Thisperson should be a subject domain expert with the authority to makedecisions and a commitment to the project timescales.

So assuming there is good userinput then the challenge of translating requirements into a designbegins. And this is no easy task as our next pointshows.

4. Users don't know whatthey want until they see it

Even with good input from theusers no amount of analysis of user requirements can take away animmutable fact that users only think that they know what they want.In truth, it’s not until they start seeing something, and using it,that they begin to really understand what they need. This isespecially true when the software is being developed for a new ideaor process that they haven’t used before.

Studies have shown that theaverage project experiences about a 25% change in requirements fromthe "requirements complete" stage to the first release. This is thefamous “scope creep” problem that besets nearly all projects. Itusually starts once the first designs begin to appear which causethe users to think more deeply about what they reallywant.

The challenge is do you a) ignorenew requirements and carry on building according to the designdocuments and risk delivering a system that doesn’t do what theusers need or b) take on changes as they arise with the result thatthe project expands and costs rise?

There is no simple answer to thisdilemma despite the fact that various techniques, such as Agiledevelopment, have evolved to make it easier to adapt to changingrequirements. Even seemingly small changes can have a big impact ona project. Each explicit requirement can lead to many more implicitrequirements (by a factor of up to 50) further complicating thesoftware.

Changing requirements during thedevelopment phase is one of the great challenges facing allsoftware developers. It can be done but don’t ever think it’s easy.And please don’t think new requirements can be accommodated withoutaffecting the timeline or the budget unless there is acorresponding removal of requirements.

5. There are no barriersto entry to become a programmer

There is one argument that statesthat software development is so hard because programming is soeasy. In other words it is relatively easy to learn how to writecode but there is a huge gap between that and delivering greatsoftware.

One could possibly equate it tolearning a new language. Yes you may pick up the grammar andacquire a reasonable vocabulary but that’s a whole different ballgame to having a fluent two-way discussion with some nativespeakers.

Various studies have shown thatthe productivity ratio between different grades of developer can beas high as 28:1. With that in mind it you surely would only want tohire the best developers. Unfortunately this is not easy as greatdevelopers are a very rare commodity.

There is no barrier to entry intothe programming world and thus it is awash with many poorprogrammers who adversely affect projects. In addition, evenpotentially good young developers will still make mistakes that amore experienced developer will have learned to avoid.

It really is worth paying more fora top-class experienced developer. They will do things quicker, andbetter and with less code. Your project will be delivered quickerand will have fewer defects. They will save you money now and theywill also save you money through the life of the system in supportand maintenance costs.

6. All software isaffected by external factors

Physical structures obey physicallaws e.g. they are affected by gravity, mass, atmosphere etc.Through thousands of years of learning much is known about thephysical world and can therefore be modelled andpredicted.

Software is “mindware” andtherefore doesn’t obey physical laws but it usually must conform toexternal constraints such as hardware, integration with othersoftware, government regulations, legacy data formats, performancecriteria, scalability etc.

Understanding and catering for allof these external factors is a near impossible task. Even aseemingly simple requirement, such as supporting multiple browsers,exponentially increases the difficulty of both building and testingsoftware. If you then add in a requirement to support multipleversions of each browser then you are again exponentiallyincreasing the complexity and the difficulty.

7. Estimating is an artnot a science

Given the premise that all newprojects are custom built, that there are no pre-built components,that the project will suffer from scope creep and that the level ofskill across the development team is usually varied then it is nowonder that estimating the duration of the project can never be ascientific exercise. There are too many unknowns. If you’ve neverbuilt the same software before with the same team then how can youknow how long it will take?

Of course experience guides you inyour estimating and the more experience you have the more likelyyou will be to anticipate the unknowns. Too many projects run overbecause overly optimistic estimates are set by inexperienced peoplewho expect everything to flow smoothly and who make no allowancefor the unknowns.

Over the last 10 years the AgileDevelopment method has emerged as a means of addressing theseestimating issues. Whilst this is generally a more reliable way tocontrol projects timescales, and therefore the cost, it is notsuitable for all projects or even on some parts ofprojects.

Where projects involve complexexternal interfaces or new technology is being used then estimatesbecome even harder to get right. These are risks that are oftenhard to quantify up-front and are usually only uncovered as thework gets done.

Summary

A software application is like aniceberg – 90% of it is not visible. The major complexity in theapplication lies below the waterline and is invisible to the user.The next time you are wondering why software projects appear sodifficult to get right you might perhaps spare a thought for thedevelopers. They are generally working hard to deliver on timeagainst a tidal wave of challenges and complexity.