关闭

转载:7 Reasons Why Software Development Is So Hard

193人阅读 评论(0) 收藏 举报
分类:

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

0
0
查看评论

Top Five Reasons Why AJAX Is So Hard

原文: http://www.infragistics.com/hot/how-we-make-ajax-easy.aspx#WhyIsAJAXSoHard5th :: Emerging Best Practices and Patterns - Not long ago, there w...
  • qsdnet
  • qsdnet
  • 2007-04-11 13:41
  • 664

为什么深度神经网络难以训练Why are deep neural networks hard to train?

Imagine you're an engineer who has been asked to design a computer from scratch. One day you're working away in your office, designing logical...
  • GarfieldEr007
  • GarfieldEr007
  • 2016-03-20 14:00
  • 1446

Adt-Bundle v22.3.0升级到v23.0.7时出错

最近想把Adt-Bundle  v22.3.0升级一下,结果发现用help->Install New Software在线升级会报错: Cannot complete the install because of a conflicting dependency. ...
  • yzpbright
  • yzpbright
  • 2015-08-25 21:24
  • 2136

精益软件开发(Lean Software Development)

Introducing Lean Software Development IntroductionAs software systems grow more complex and more people become involved, managing software develo...
  • pengjian007
  • pengjian007
  • 2008-06-18 14:51
  • 2952

ln 命令用法 hard link 与 symbolic link 区别 分析

Hard Link (实体链接, 硬式连接)     首先要知道inode。它就像一个指向档案的指针,档案的内容由inode的记录来指向。所以读取一个档案内容可以有多个文件名对应一个文件的inode号码,这就是hard link。    举个...
  • fansongy
  • fansongy
  • 2011-08-17 20:30
  • 5617

解读微软SDET(Software Development Engineer in Test)

以下内容转自:http://zhidao.baidu.com/question/156694209.html 关于微软SDET职位,是一个很有争议的话题。 我不想说SDET多么多么好,也不想说它多么糟,这里我以一个微软(总部)SDET的身份来讲一下,给大家最真实第一手
  • chenglin1986
  • chenglin1986
  • 2011-10-09 14:48
  • 1095

How do you start IBM Rational Software Development Platform products in a language

You want to use the product in a language in which you are more proficient. You can change the default language setting by either passing an argum...
  • jqjqejq
  • jqjqejq
  • 2015-08-06 13:33
  • 151

7 More Reasons Why Web Apps Fail

URL: http://bokardo.com/archives/7-more-reasons-why-web-apps-fail/ 7 More Reasons Why Web Apps FailThis is a follow-up to my post 7 Reasons Why Web Ap...
  • coofucoo
  • coofucoo
  • 2006-05-19 11:47
  • 1179

Lean Software Development的七个原则与管理观念

在agilesoftwaredevelopment.com看到一篇Seven Principles of Lean Software Development才知道原来Agile Software Development和日本制造的JIT有这样的渊源关系. 依据作者的说法:日本最赚钱的汽车制造商Toy...
  • esebella
  • esebella
  • 2009-12-02 12:59
  • 1116

Revit二次开发(1):必备条件与安装

Revit开发需要三个条件 1.Revit 201*产品,可以从Autodesk官网上去下载:www.autodesk.com.cn; 2. Revit 201* SDK,    (从Revit产品安装包里可以找到,在其中搜索SDK可找到,找到后安装即可); 3...
  • u012141979
  • u012141979
  • 2015-12-23 16:45
  • 725
    个人资料
    • 访问:51266次
    • 积分:1582
    • 等级:
    • 排名:千里之外
    • 原创:157篇
    • 转载:32篇
    • 译文:0篇
    • 评论:2条
    文章分类
    最新评论