Software Engineering - Successful Software Development

Author

Successful Software Development - It's Not Rocket Science

dhaughey@hotmail.com

2006-08-19, 8:01 am

Hi,

Just want to point you to a rather interesting Software Development
article...

Successful Software Development - It's Not Rocket Science
http://www.4-developers.com/success...evelopment.html

Good stuff, well worth a read!

Cheers
D

Phlip

2006-08-19, 6:59 pm

dhaughey wrote:

> http://www.4-developers.com/success...evelopment.html

Ethically, if you are associated the article, you should put ANN in the
subject, and declare you wrote it, here. Otherwise you are a "sock puppet",
pretending not to have an interest in something you are promoting.

Now we get to your first ... mistake:

> Getting the Requirements
> The Mistake
> One of the cardinal sins in software development is rushing
> into a project in a peak of enthusiasm without taking enough
> time to understand what the customer really wants. This is
> one of the most common mistakes and is responsible for more
> failed software development projects and unnecessary rework
> than anything else.

> The Solution
> Get the customer requirements first and then fit the requirements
> to a solution, not a solution to the requirements. Avoid the "we
> know what you need" syndrome that still exists amongst some
> developers.

> It's a good idea to use a business analyst to gather the
> requirements as they tend to take a non-technical, objective
> view of what the customer wants.

> It's all to easy to get railroaded into 'coding' before the
> requirements are fully understood, but time spent up front
> with the customer will prevent a lot of pain and rework later.

Now that is such an appealing argument that many, many bosses follow,
fearing to lose lots of money. And your lead example cites such a loss:

> Just look at the Ministry of Defence who wasted nearly £30m
> on two IT projects alone. The first project, a communications
> system for the RAF, was abandoned because of problems
> integrating it with other systems and £21m was written off.
> The second, a pay system for the Navy, was closed when it
> became clear that the project would cost three times the
> expected amount of £18.9m. £8.7m had already been spent,
> this too was written off.

Now when I see a defense industry lose a huge amount of money, the first
thing I think is _not_ "Oh, they must have rushed to coding!" Defense
contractors are notorious for practicing "Big Requirements Up Front". They
pay an entire team to collect lots and lots of requirements, for a very long
time.

Many studies have directly correlated the size of these requirements
documents to the odds of failure. Some of these studies focussed on defense
contractors, specifically. Governments often reward these firms for
collecting lots of requirements; they get bigger contracts.

The more line-items you collect, the longer your programmers must write, and
the higher the risks get. The main risk is that a small error in
requirements will inflate into a large error in coding. The most likely
small error is the requirements gatherer will over-estimate the value of a
feature. Then programmers will work very hard on it, unaware the customer is
not waiting for it.

When these firms instead work in short iterations, surveys have shown they
get much higher odds of success by sorting features in order of business
priority, and delivering the highest value features as early as possible.
Early delivery means end-users can see if they can actually use what they
are getting. It also greatly increases the odds their next feature requests
will be valuable and relevant

So the correct answer to your "Getting the Requirements" question is
"Just-In-Time Requirements", where you delay irreversible decisions until
the last moment.

The answer to your next Mistake is much more agreeable: "What you really
need is a person with a foot in both camps." This is the Tom Peters (/In
Search of Excellence/) concept of a Customer Liaison. They should work
full-time with a team, who should coach them in jargon relevant to their
domain. They are the conduit for the feature requests.

The answer to your next Mistake is essentially Iterative and Incremental
Delivery. You restate my point that customers must get early releases.
However, you neglect the business value of the features in each release.
Many teams have treated "iterative" to mean they draw a design for
everything, cut it up into modules, and write one module at a time. Feature
requests should instead grow all modules.

The answer to your next Mistake, "Use professional testers to test the
software", obscures one of the biggest problems in software engineering.
There's two kinds of testing - Constraints, and QA. You simply said that a
team should use a professional QA department. The biggest problem in
software engineering these days is most programmers do not write automated
constraints for their own code. I refer, of course, to Design by Contract
and/or Test Driven Development. Programmers should write test cases, for
every line of every function, as the backbone of the entire QA system.

--
Phlip
[url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!

JXStern

2006-08-19, 6:59 pm

On 19 Aug 2006 03:52:55 -0700, dhaughey@hotmail.com wrote:
>Just want to point you to a rather interesting Software Development
>article...
>
>Successful Software Development - It's Not Rocket Science
>http://www.4-developers.com/success...evelopment.html

>A non-functional prototype can be produced quickly and cheaply

Non-functional, like (linked) screen-mocks?

Not worthy of the term "prototype".

The whole field of iterative/agile development obsoletes the very
concept of "prototype"

Your article smacks of conventions thirty years out of date.

J.

David Lightstone

2006-08-20, 7:00 pm

"Phlip" <phlipcpp@yahoo.com> wrote in message
news:FWFFg.11202$9T3.852@newssvr25.news.prodigy.net...
> dhaughey wrote:
>
>
> Ethically, if you are associated the article, you should put ANN in the
> subject, and declare you wrote it, here. Otherwise you are a "sock
> puppet", pretending not to have an interest in something you are
> promoting.

Isn't this repremand sort of like the pot calling the kettle black

>
> Now we get to your first ... mistake:
>
>
>
>
>
> Now that is such an appealing argument that many, many bosses follow,
> fearing to lose lots of money. And your lead example cites such a loss:

In the proper contect your "objection" is meaningful. In this one probably
not. The above - "problem/solution" is almost a tautology. Knowing the
requirements and having them written down are too vastly different things.
(Just what are the requirements in an exploratory type development anyway)

>

You are running an interesting interpretation here.
(1) Objecting to managers taking on an effort to formulate requirements
(2) Using an example where interface requrements were poorly developed to
justify not formulating requirements (the communications example)
[color=darkred]
>
> Now when I see a defense industry lose a huge amount of money, the first
> thing I think is _not_ "Oh, they must have rushed to coding!" Defense
> contractors are notorious for practicing "Big Requirements Up Front". They
> pay an entire team to collect lots and lots of requirements, for a very
> long time.
>
> Many studies have directly correlated the size of these requirements
> documents to the odds of failure. Some of these studies focussed on
> defense contractors, specifically. Governments often reward these firms
> for collecting lots of requirements; they get bigger contracts.

Tell me who made the scope so large, the development process or the
customer? (reward or not, the number of requirements is consistent with the
scope of the project, otherwise there would be massive rejection)

Size or requirements correlates with probability of failure, not doubt about
it. Any suggected solutions.
Approved candidates are:
(1) Only work on projects without requirements
(2) Only work on projects that have limited scope
(3) Understand the relationship between deliverables and compensation when
developing for the Government before construction imaginary business models

>
> The more line-items you collect, the longer your programmers must write,
> and the higher the risks get. The main risk is that a small error in
> requirements will inflate into a large error in coding. The most likely
> small error is the requirements gatherer will over-estimate the value of a
> feature. Then programmers will work very hard on it, unaware the customer
> is not waiting for it.

Somehow I suspect that you have never worked on a Government project. No
doubt you have read about their existance, and have excelent ability to
develop linear models for non-linear systems (accuracy of reasoning model
subject to question).

I take it that you do believe that once the requirements are written, the
coders have at it, right? (skip the design studies, right?)

>
> When these firms instead work in short iterations, surveys have shown they
> get much higher odds of success by sorting features in order of business
> priority, and delivering the highest value features as early as possible.
> Early delivery means end-users can see if they can actually use what they
> are getting. It also greatly increases the odds their next feature
> requests will be valuable and relevant

You are describing an exploratory development style. A situation where
global risk of failure is quite possible (an inherant characteristic of the
problem - the customer does not know what is really needed). Now the only
question is whether you actually believe that success is guarenteed by the
approach that you advocate (or whether you naievely believe it).

Comparing the success of a non-exploratory project, to the failure of
exploratory projects can only be termed propaganda

Obviously you erroneously believe that business requirements can be
prioritiezed, that is they are an ordered set. Partially-ordered set is the
correct answer here.

Take a simple (well not so simpled) example of an engineering problem
possibly experienced by the developers of a very heavy armoured vehicle.
Should the fuel tanks be sealed or not? What is the buisiness value of doing
so and what is the business value of not doing so? How do you prioritize the
value of a controlled fuel spill when the fuel tank experinces a concussive
shock (as opposed to being ruptured by a projectile or explosion device) vs
a random rupture when the fuel tank experiences a concussive shock ? (this
might occur when one massive vehicle rams another, say at the intersection
of two urban streets rather than in an open field).

>
> So the correct answer to your "Getting the Requirements" question is
> "Just-In-Time Requirements", where you delay irreversible decisions until
> the last moment.

Pray tell how do you know a priori which of these decisions will in fact be
irreversible?

>
<snip>

>
> --
> Phlip
> [url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!
>

Thad Smith

2006-08-24, 4:01 am

David Lightstone wrote:
> "Phlip" <phlipcpp@yahoo.com> wrote in message

>
> Isn't this repremand sort of like the pot calling the kettle black

I haven't seen any "here's an interesting article I found" post from
Phlip to his own work, so no, I don't think so. The OP wasn't that
blatant, but the remark of "Good stuff, well worth a read!" implies to
most people that you are not the author.

--
Thad

David Lightstone

2006-08-24, 8:00 am

"Thad Smith" <ThadSmith@acm.org> wrote in message
news:44ed6a67$0$7459$892e0abb@auth.newsreader.octanews.com...
> David Lightstone wrote:
>
>
> I haven't seen any "here's an interesting article I found" post from Phlip
> to his own work, so no, I don't think so. The OP wasn't that blatant, but
> the remark of "Good stuff, well worth a read!" implies to most people that
> you are not the author.
>

I must have missed the " ... I found ... " implication

>
> --
> Thad

Sponsored Links