Weblogs Forum - Frequently Forgotten Fundamental Facts about Software Engineering

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Frequently Forgotten Fundamental Facts about Software Engineering

18 replies on 2 pages. Most recent reply: Nov 19, 2008 12:27 PM by nes

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 18 replies on 2 pages [ 1 2 | » ]

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Frequently Forgotten Fundamental Facts about Software Engineering (View in Weblogs)

Posted: Nov 7, 2008 11:18 AM

Summary
A useful collection of observations about our profession.

This article by Robert Glass was originally printed in IEEE Software in 2001.

Derek Parnell

Posts: 22
Nickname: derekp
Registered: Feb, 2005

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 9, 2008 3:20 PM

Wow! I've been preaching most of these facts for years and I seemed to be a voice in the wilderness. I think that only seasoned developers are aware of these truths. I'm so glad that I someone has put them all down on one page. Of course that does not mean that the pointy-haired people will ever grok them.

If I was to add anything it might be to mention that developers are not testers and visa versa. A fact often overlooked by both parties and their managers. Actually one can throw analysts in to that equation too.

Another fact in a similar vein is that software engineers do not generally have the skills to adequately document their work for non-engineer readers. There are exceptions of course, like in everything else, but they are still exceptions .

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 10, 2008 1:11 AM

Quite useful list to print out and glue on all walls in software companies, as a reminder for how things can go wrong. However, a few things I see different/complementary:

10% increase in problem cmplexity => 100% increase in solution complexity is IMO an overstatement. Say you have a problem of complexity 1, and one of complexity 2. The problem of complexity 2 would require a solution 2^5 ~ 64 times more complex than the problem of complexity 1 (1.1^6 ~ 2), if the statement in the article was right. My experience is that doubling the complexity yields maybe a three to five times more complex solution, but in no way a 32 times more complex solution.

Good programmers vs. weak programmers: this is IMO a matter of policy. Why do you hire somebody who can't do his job properly in the first place? Second, it's also a matter of policy: having an excellent programmer work on a badly designed application, under the autocratic rule of a bad project manager, is the best recipe to have his productivity and the quality of his code drop sharply, besides creating the best possible conditions for him to leave without regrets.

QUality 1: quality is the result of a good process, not of "heroic" individual efforts during a project. In a environment organized towards achieving it, quality goes unnoticed. You only notice it when it's missing.

Quality 2: software development is a business for most of us. Therefore, quality should be judged in terms of business: how much is the customer willing to pay for quality and what does it cost me to deliver quality? Each of the quality attribuites enumerated in the list has a cost. This cost should not be imposed on the customer if the attribute is of no use to the customer.

Question: don't agile methods somewhat contribute to unstable requirements? I mean, in scrum you do a cycle in a few weeks. For most modern applications, even for small ones, the number of stakeholders is large. You usually cannot coordinate all stakeholders to obtain agreement about the requirements during a few weeks, but with agile methods, you already devliver something that works after a few weeks. Then start changing it, because you keep getting new requirements. Costs increase, overall duration increases. And there's no guarantee that what you developed initially is usable as delivered.

To a greater extent, and also heavily mean-ish: isn't it then that agile methods are part of the problem, rather than of the solution to the many problems that plague software development?

In particular, this issue was illustrated by a project we are about to finish this week. The requirements and specification documents were rushed out to the programmers. As a consequence, the data model is flawed - in such a way that it doesn't support business requirements. The only way to fix it would be to completely scrap that part and build it anew. I estimate that using several successive refactorings would be more expensive, since the gap between implementation and actual requirements is quite large. It may be that it is not an agile process'es fault that you don't get requirements right right from the start (after all, since we have similar older experiences with this customer, we tried to make the process as non-agile as possible, and to question every requirement and design decision which smelled bad), but I think an agile process favors such situations, in which you build on insufficiently verified and reviewed requirements.

And another question: why do we think that software development as an industrial process is so much different than other industrial processes? It may be that the relations and proportions are distorted, in that for instance in car manufacturing design costs are offset by several orders of magnitude by the actual manufacturing costs, while you more or less don't have manufacturing costs for custom-built software, and the relation for off the shelf software depends on the particular product, but both the car industry and the software industry have manufacturing and design processes (I consider coding to be part of design, similarly as doing the blueprints after the technical solutions were discussed and agreed upon is part of car design). It surely is a matter of perception with customers, which cannot notice these differences, and I can understand this. But why do people inside the industry hold on to this idea, that software development and car manufacturing (or building skyscrapers, or planes, or growing flowers, for that matter) are so different? After all, a software product is as much the brainchild of a programmer as a car design is that of a car designer, or as a park design is that of a skilled gardener, or the interior of a building that of an interiors designer. You use engineers as programmers, gardeners doing parks often also have an engineering degree in horticulture, you also use engineers for designing cars. Skilled designers use a lot of geometry and some physics to do interiors designs that work (just an example: smart kitchen design can save you quite some tens of miles of walking each month). So where's the big difference between software and anything else?

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 10, 2008 2:56 AM

> Good programmers vs. weak programmers: this is IMO a
> matter of policy. Why do you hire somebody who can't do
> his job properly in the first place?

Simply because most recruitment/selection procedures are unable to distinguish the qualities of the programmer in advance of offering the job. The only way (I think) to do this is to examine their actual track record (as opposed to the CV the programmer provides). Unfortunately, there are many reasons why this isn't possible either.

> QUality 1: quality is the result of a good process, not of
> "heroic" individual efforts during a project. In a
> environment organized towards achieving it, quality goes
> unnoticed. You only notice it when it's missing.

There must be a word for something that is only visible when it's not there? If not, there ought to be.

> Quality 2: software development is a business for most of
> us. Therefore, quality should be judged in terms of
> business: how much is the customer willing to pay for
> quality and what does it cost me to deliver quality? Each
> of the quality attribuites enumerated in the list has a
> cost. This cost should not be imposed on the customer if
> the attribute is of no use to the customer.

The catch is that quality targets and functionality targets are generally not the same thing and it can be very difficult to reconcile the two. The result is often software that has too many targets to meet and, consequently, is too big/slow/late/etc.

> Question: don't agile methods somewhat contribute to
> unstable requirements? I mean, in scrum you do a cycle in
> a few weeks. For most modern applications, even for small
> ones, the number of stakeholders is large. You usually
> cannot coordinate all stakeholders to obtain agreement
> about the requirements during a few weeks, but with agile
> methods, you already devliver something that works after a
> few weeks. Then start changing it, because you keep
> getting new requirements. Costs increase, overall duration
> increases. And there's no guarantee that what you
> developed initially is usable as delivered.

I thought the thing about Agile Development was precisely that you could guarantee that what you developed initially would not be what you delivered, given that its central assumption is that all your requirements are unstable (or even just plain wrong). The important thing is what you finally deliver (given all the other constraints) not the number of iterations involved nor the fact that the initial spec was wrong.

> And another question: why do we think that software
> development as an industrial process is so much different
> than other industrial processes?

Because it rarely produces a readily visible product, constructed from visible components. People can naturally deal with stuff they can see and touch. Software is generally only visible by its effects on the outside world and not as a thing in its own right. I think that it's that abstraction that makes it different.

> After all, a software product is as much the brainchild of
> a programmer as a car design is that of a car designer, or
> as a park design is that of a skilled gardener, or the
> interior of a building that of an interiors designer. You
> use engineers as programmers, gardeners doing parks often
> also have an engineering degree in horticulture, you also
> use engineers for designing cars.
:
> So where's the big difference between software and anything else?

In theory none; but everyone can look at a car, a park or a building and pass judgement on it and have opinions on what are the good and bad bits. Few people (including those involved with software development) will ever be in any position to make a useful judgement about a DBMS implementation or the software in your camera.

Ed Kirwan

Posts: 3
Nickname: kirwan
Registered: Nov, 2007

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 10, 2008 3:22 AM

There's that tricky term again, "Complexity." It may be difficult to define, but surely it's not impossible. Making unproven statements about undefined terms somehow degrades the title of this piece.

"P1. The most important factor in attacking complexity is not the tools and techniques that programmers use but rather the quality of the programmers themselves."

That is good news, as encapsulation is already a powerful factor in attacking one type of complexity, see encapsulation theory:
http://www.edmundkirwan.com/

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 10, 2008 8:22 AM

> > Quality 1: quality is the result of a good process, not
> of
> > "heroic" individual efforts during a project. In a
> > environment organized towards achieving it, quality
> goes
> > unnoticed. You only notice it when it's missing.
>
> There must be a word for something that is only visible
> when it's not there? If not, there ought to be.

'Hole' or 'void', perhaps? Those are the simplest terms in English that I can think of that are defined in terms of absence. This is pretty inherent in human endeavors I think. For much of my life I didn't think much about how well a given chair supported my weight. It wasn't until i had a chair collapse on me or come close to doing so that I started to appreciate the quality of a solid chair. "You don't miss your water until the well runs dry" as the saying goes.

A co-worker of mine hypothesized that it's the developers that consistently deliver poor quality and then heroically fix the issues that are often seen as the best developers by management. The developers that deliver robust systems that run without issues have much less visibility. It's very cynical but I feel there's some truth to it.

Daniel Jimenez

Posts: 40
Nickname: djimenez
Registered: Dec, 2004

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 10, 2008 8:34 AM

> This article by Robert Glass was originally
> printed in IEEE Software in 2001.

He expands on this list and fleshes out the research behind each point in his wonderful book, Facts and Fallacies of Software Engineering [http://www.amazon.com/Facts-Fallacies-Software-Engineering-Development/dp/0321117425/].

Highly recommended.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 10, 2008 8:57 PM

I'm afraid I'm starting to troll - please warn if so.

Three ideas: quality from a business point of view only, again a rant against agile methods, and a return to the comparison between software products and other products.

Why I think these issues are all important in the context of this thread: all of them are if not forgotten but often ignored facts about software engineering. Of course, as long as I'm not proven wrong.

A business is designed to make money. Social responsibility or other aspects are secondary to making money. Quality of a software product should be judged by how much money it is making for a company. If you an reduce costs without cutting into your profit, why would this be a bad thing? Of course, you shouldn't consider only the benefits for three months in advance, when you do cost estimations, but nevrtheless, cost issues are IMO the most important thing to define what quality means for a particular product.

Example: you have an off the shelf product with an estimated life cycle of 25 years. It would be bad quality management to ignore code maintainability - if you accept deterioration of maintainability early in the product's life cycle, your costs later on are bound to skyrocket. But it is perfectly acceptable and a sound business decision that once you reach the final stage of development you cut investments in maintainability. Even if this means getting all programmers upset.

Coding an application based on unstable, potentially wrong requirements, only in order to make some platform available for discussion, and evolving something usable by successive iterations, as far as I can recall, was formerly known as prototyping, not agile development. This is bound to be an expensive process, especially if you deliver production quality code (i.e. at least unit tested code) with each iteration. Why would you want to make a definitely expensive process the default? I don't argue for an extremely heavyweight and highly regulated process, I just don't think that it is always a good idea to deliver often and start coding right away. It's sometimes like those generals sending in troops to attack a target which is far out of reach: they may eventually take it, but at what cost? Modern businesses who do not make software think lean, not agile. Why would lean be a bad idea in software? Don't tell me agile means lean, it doesn't. If you deliver just for the sake of it, knowing that what you deliver is unusable due to flawed requirements, it means catering to the customer's demands, rather than to his needs, and making him pay for it.

When you buy a new car, you go and have a look at it. You may read some data sheet. You probably take a test drive. You seldomly if at all look under the hood. But you definitely never screw open the gearbox or ask to see the blueprints. When you assess a software product, you start it up, click some menus and buttons, maybe have a look at the help file or the user manual. As a regular user, you don't review the sources, neither do you run it through a debugger. I can see no essential difference.

My browser and the bus getting me to work are similarly concrete to me. I don't care putting my hands on the screen (unless it's atouchscreen), nor do I care to touch the bus'es greasy engine. Or smelling or tasting either of them. I just think it makes sense to assess either of them (and their abstractedness) through the attributes that really matter to me.

Why then, if products of both the software industry and those of (almost) any other industry are perceived and judged mostly similarly, would processes in software development and in other industries be so much different? Why would the problems plaguing software development be different and have different solutions than the ones occuring in other industries? Assuming that the nature of the whole process is different, and not trying to learn from other industries based on this assumption is IMO definitely counterproductive.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 11, 2008 10:57 AM

Stable requirements are always desirable using agile methods or not, agile just tries to find a way to minimize the cost to the project when they do change (as is often the case).

The difference is this: you try to get the requirements as stable as possible and work on your system --for example-- for 2 weeks on the part most important to the business and show the results. The user will change the requirements on that core part of the application, and you adapt the 2 weeks work to the new realities. After 2 weeks you show it again, and so on until it is mostly what the users want. At that point you should have a stable core, if that cannot achieved after a couple of months you declare them a failed feasibility try and that the requirements are too unstable for automation and are better done manually by humans. Otherwise you add the next thing in priority and iterate over that, etc.

An iterative method avoids 2 problems of the sequential method:

1. You discuss requirements forever in the abstract and nothing gets ever done. (Analysis paralysis)
2. You set the requirements in stone after a certain amount of analysis. After the product is done according to those requirements the users tell you that they won't use it unless some core parts of the application change. The whole application depends on those parts so you have to rewrite everything instead of just those parts.

Comparing writing software with manufacturing cars is misleading also. Cars using the same basic concepts have been around for 120 years now. Everybody and his grandparents have seen one and knows what to expect. Even modern cars like the Chevrolet Impala for example has been in production in different incarnations since 1958. Custom software is created from scratch, and in some cases even the wheel gets reinvented. Creating custom software is more like doing the haircut for a lady than mass producing a glorified cart.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 12, 2008 1:42 AM

> Stable requirements are always desirable using agile
> methods or not, agile just tries to find a way to minimize
> the cost to the project when they do change (as is often
> the case).

Cost is exactly my point. IMO, it is more cost-effective to iterate more on the requirements, if they are recognized as being unstable, than to start iterating directly on code. You may be able to tell the customer the project will surely be a failure because of unstable requirements before you even start coding, which saves the customer a lot of money.

IMO, Iterations on code make sense only for addressing two problems: requirements changes due to causes external to the system/business process you model (for instance, you initially devised your app to use a built-in directory because no external directory was available, and in a later iteration you add support for LDAP and scrap the internal directory, because a company-wide LDAP directory has come alive), and additional features. Both these situations have nothing to do with unstable/blurry requirements.

> An iterative method avoids 2 problems of the sequential
> method:
>
> 1. You discuss requirements forever in the abstract and
> nothing gets ever done. (Analysis paralysis)

As far as I can tell, analysis paralysis is usually a politics problem, which cannot be addressed in code. If there's the will and the willingness to cooperation between the essential stakeholders, you don't get analysis paralysis. Otherwise, agile development will not be able to solve the non-technical problems. Alternatively, analysis paralysis may be a sign that the service provider is not able to provide a solution, or that the porblem simply has no solution (for instance due to cost issues). It should be better to find out about this before you start coding, don't you think?

> 2. You set the requirements in stone after a certain
> amount of analysis. After the product is done according to
> those requirements the users tell you that they won't use
> it unless some core parts of the application change. The
> whole application depends on those parts so you have to
> rewrite everything instead of just those parts.

Every modern project management process includes a process/procedure for handling change requests. It doesn't matter if it's about construction, boat building, designing a car or creating a software app. Setting requirements in stone is something classical project management got over a long time ago.

On the other hand, agile development does not address the problem you describe. Thorough refactoring and proper design do, but these are not monopolized by agile methods, AFAIK.

> Comparing writing software with manufacturing cars is
> misleading also.

Of course it is. I compared designing a car with software development, not manufacturing it. (On a side note, both processes tend to be iterative, only car manufacturers do not do blueprints for the car before deciding what the blueprints have to contain, and try to minimize iterations - which is something agile methods tend to maximize, as far as my understanding goes.)

> Cars using the same basic concepts have
> been around for 120 years now. Everybody and his
> grandparents have seen one and knows what to expect.
> Custom software is created from scratch, and in some
> cases even the wheel gets reinvented.

Your comparison may have had some meaning maybe 20 years ago, but doesn't hold water anymore. Any person using a computer at work and at home, and maybe also using a smartphone or some other sort of gadget has similar experience with software as with cars, I think. At least in the category of personnel I'm are interested in - people involved in consuming software services.

> Creating custom software is
> more like doing the haircut for a lady than mass producing
> a glorified cart.

Talk to a hairdresser. He'll tell you that most haircuts are routine to him. On the other hand, One haircut usually takes less than half an hour, while a simple class, not to talk about a small application, takes significantly more (unless it's of the hello world family). A class is often routine. Only, the big picture, putting all classes together isn't. Whereas there are few hairdressers put in a situation to orchestrate the proper match of tens, hundreds or even thousands of classes. So i'd choose another comparison, for instance between an architect designing a garden and a web designer, or between a civil engineer designing a bridge and a software engineer.

To summarize: I don't advocate against iterations, thorough refactoring, continuous integration, peer review, or other techniques that agile methods promote. Only, my understanding of agile methods (which may be wrong) is that agile methods promote quickly rushing to code. Which IMO isn't always the smartest thing to do. Rushing to code potentially increases the number of iterations unnecessarily, and thus increases costs and duration.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 12, 2008 6:29 AM

> To summarize: I don't advocate against iterations,
> thorough refactoring, continuous integration, peer review,
> or other techniques that agile methods promote. Only, my
> understanding of agile methods (which may be wrong) is
> that agile methods promote quickly rushing to code. Which
> IMO isn't always the smartest thing to do. Rushing to code
> potentially increases the number of iterations
> unnecessarily, and thus increases costs and duration.

I'm not an expert on Agile by any stretch of the imagination and what I have mixed feelings about it. Specifically with respect to starting development right away, I kind of see your point but I think there is some benefit to this.

I think in a perfect crystalline world where designs are right the first time, you are right, the extra iterations would be a waste. But in my experience the following things change the equation:

* Most requirements are not accurate. Most people making the requests are unable to properly verbalize what they want in a software application.

* The farther away a deadline is, the less work developers do. I'm not saying people are lazy per se, but that (especially inexperienced) people don't feel a lot of pressure when the deadline is months or a year away.

* Almost every software project I've been involved in seemed a lot simpler before the development started. Predictions made in the analysis and design phase are almost always highly optimistic.

I'm not saying that getting into development quicker is the only answer but it's one that seems to work. So while in theory, it's a waste of time and money, it actually saves time and money and produces a better result. the primary benefit it reduces the risk of producing the wrong thing, which in my experience is pretty high in the waterfall approach.

Considering your car analogy, car designers build models or new designs and even build prototypes of cars long before the production designs are complete. This helps to guarantee that management is going to get what it wants. They don't go from design to the production line.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 12, 2008 8:15 AM

> > Stable requirements are always desirable using agile
> > methods or not, agile just tries to find a way to
> minimize
> > the cost to the project when they do change (as is
> often
> > the case).
>
> Cost is exactly my point. IMO, it is more cost-effective
> to iterate more on the requirements, if they are
> recognized as being unstable, than to start iterating
> directly on code. You may be able to tell the customer the
> project will surely be a failure because of unstable
> requirements before you even start coding, which saves the
> customer a lot of money.
>
I am in complete agreement. Agile is mostly a benefit when requirement change after the code is already written.

> IMO, Iterations on code make sense only for addressing two
> problems: requirements changes due to causes external to
> the system/business process you model (for instance, you
> initially devised your app to use a built-in directory
> because no external directory was available, and in a
> later iteration you add support for LDAP and scrap the
> internal directory, because a company-wide LDAP directory
> has come alive), and additional features. Both these
> situations have nothing to do with unstable/blurry
> requirements.
>
The thing that agile developers recognize is that completely stable requirements are an illusion. There is no such thing. At some point you have to say: this is good enough and realize that those requirements and documentation you wrote will be valid for about two weeks and then are good for the waste bin.

I will qualify that I am talking about business applications like custom built billing, sales, CRM. I read that technical oriented systems like missile control or plant automation have much more stable requirements (I guess the laws of physics don’t change as often as marketing campaigns). In those environments it probably makes sense to document more of the details.

> > An iterative method avoids 2 problems of the sequential
> > method:
> >
> > 1. You discuss requirements forever in the abstract and
> > nothing gets ever done. (Analysis paralysis)
>
> As far as I can tell, analysis paralysis is usually a
> politics problem, which cannot be addressed in code. If
> there's the will and the willingness to cooperation
> between the essential stakeholders, you don't get analysis
> paralysis. Otherwise, agile development will not be able
> to solve the non-technical problems. Alternatively,
> analysis paralysis may be a sign that the service provider
> is not able to provide a solution, or that the porblem
> simply has no solution (for instance due to cost issues).
> It should be better to find out about this before you
> start coding, don't you think?
>
Again I am in agreement. But then there are projects in which thousands of pages of documentation are written at which point no money is left to do any programming. But I guess 10000 pages of nice documentation with all the requirements is so much better investment than a half-working program.

> > 2. You set the requirements in stone after a certain
> > amount of analysis. After the product is done according
> to
> > those requirements the users tell you that they won't
> use
> > it unless some core parts of the application change.
> The
> > whole application depends on those parts so you have to
> > rewrite everything instead of just those parts.
>
> Every modern project management process includes a
> process/procedure for handling change requests. It doesn't
> matter if it's about construction, boat building,
> designing a car or creating a software app. Setting
> requirements in stone is something classical project
> management got over a long time ago.
>
> On the other hand, agile development does not address the
> problem you describe. Thorough refactoring and proper
> design do, but these are not monopolized by agile methods,
> AFAIK.
The way contracting software construction is often still done is to have a contract written by lawyers of the software company that contain the requirements of an application to be delivered. What you get is a worthless piece of software that exactly conforms to the minimum requirements of the contract.

>
> To summarize: I don't advocate against iterations,
> thorough refactoring, continuous integration, peer review,
> or other techniques that agile methods promote. Only, my
> understanding of agile methods (which may be wrong) is
> that agile methods promote quickly rushing to code. Which
> IMO isn't always the smartest thing to do. Rushing to code
> potentially increases the number of iterations
> unnecessarily, and thus increases costs and duration.

Incremental and iterative development, refactoring, automated testing and continuous integration are important agile concepts. It is about getting a product out that is nice, small and simple and keep organically growing it. I don’t know what rushing code without requirements would be called, but I don’t think that is what agile is about. In the end agile really is a reaction to a popular notion in software engineering that if we just get the right methods, tools, documentation and contracts, people become irrelevant.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 12, 2008 12:45 PM

> Considering your car analogy, car designers build models
> or new designs and even build prototypes of cars long
> before the production designs are complete. This helps to
> guarantee that management is going to get what it wants.
> They don't go from design to the production line.

Exactly. Only, they thoroughly prepare before starting to build a prototype. In fact, they handle each prototype as a separate project, they even handle intermediate phases for experimenting with parts of the future prototype as separate projects. They are so systematic that a software engineer would probably go mad soon after entering this world - they work just as a well-designed procedural program. And they are the most cost-efficient industry I know about - what other industry lives off 5 to 7% profit? Which is exactly my issue with agile methods: it seems to me (without being an expert), that by simply applying the agile manifesto you tend to always work on prototypes and not even call them that way. You get to be less lazy than it's good for you.

I remember a very funny definition/comparison of efficiency/effectiveness. Say you need to climb on a wall, and you have a ladder. Climbing the ladder with the best possible speed is efficiency. Leaning the ladder against the right wall is effectiveness. It seems to me agile methods tend to maximize efficiency, but in a way that harms effectiveness. No matter how efficient you are, if you have to climb down and lean the ladder against a different wall several times, you aren't effective. Some lazy bum taking a moment to choose the right wall is surely going to get to the top of the right wall sooner than you. Even if you double your efficiency, it won't increase your effectiveness, unless you change your way of doing things.

Thinking of it, it seems to me it isn't the problem of changing requirements which potentially led people into believing that starting to code right away and delivering often is a good thing to do. Rather, the ineptness of most people to write usable and maintainable documentation. Surely you prefer to start coding and get corrections from the customer, rather than get a thousand pages of amorphous, redundant and self-contradicting documentation which nobody understands, and trying to figure out what to do. But again, that's not a problem intrinsic to a non-agile process, it's a problem of how the documentation is done.

Why not try an agile process on spec and design documentation, before you start coding? Refactor it thoroughly, keep it minimalistic, provide many revisions of it to the customer for review, until the customer says it is OK. This is potentially a way of reducing the number of iterations - you are likely to have a usable and pretty stable spec after such a process, I think. With less effort than you would need to invest to actually implement all the revisions of the spec.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 12, 2008 2:14 PM

> Why not try an agile process on spec and design
> documentation, before you start coding? Refactor it
> thoroughly, keep it minimalistic, provide many revisions
> of it to the customer for review, until the customer says
> it is OK. This is potentially a way of reducing the number
> of iterations - you are likely to have a usable and pretty
> stable spec after such a process, I think. With less
> effort than you would need to invest to actually
> implement all the revisions of the spec.

I don't need to try it. I see it every day. In our company they are at least smart enough to have business analysts do the requirements documentation so programmers don’t have to suffer through this. Let me describe a typical iteration:

So let’s say a department wants a new screen for an application. Easy enough, the business analyst organizes 5 or 6 meetings lasting over 1 hour during a couple of months, each with a dozen people: the bosses, some important users, etc. On each one they design the screen on paper, on the white board, talk about how it will work, business rules, etc. Then the business analyst will have a meeting with the programmers were we tell him they are all stupid, that we don’t need an entry field for age when we already have a date of birth or such things (actually we try to be nice; the business analyst is helping us manage the users after all and they are pretty good at filtering 99% of stupid ideas). After that the business analyst schedules other meetings were he presents the changes to requirements requested by the programmers. After everybody is more or less happy with the document, on a sign off meeting all present users will sign off on the written requirements and specs.

Next the programmers will then implement the screen as written in the spec and the business analyst will write some simple documentation on how to operate the new screen. Within a couple of weeks the new screen will be ready for testing from the user. When the users start testing the program they will complain that they understand neither the screen nor the documentation, so the business analyst will go on site to patiently explain the operation to the users in person. At that point the users start a mutiny saying that the new screen is cumbersome to use and can’t be put into production in its current state and request 20 new changes. A new round of changes get approved and signed off.

After the programmers have worked for another week or so to do all the changes to the code, a second version is ready for testing. The users will still complain that it is not good but at this point the bosses realize that the time is out and that the new functionality has to be ready for a certain campaign, etc. and request to move it into production anyway. After a couple of months in production the users become accustomed to the clunky interface and will be pretty productive with it. Any improvement or change to the screen after that point will produce wrath and bile in a number of expert users of the application.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 12, 2008 8:16 PM

> I don't need to try it. I see it every day. In our company they are at least smart enough (...)

I think there's some merit in your conmpany's approach. Only, I don't understand why the business analyist is the one to design a screen - he's there to map out processes and gather requirements, isn't he? It is my experience that business users are in most cases smart enough to be able to talk about an application in terms of processes, without needing reference to a screen prototype, if you remember you need to talk their language. If you get the processes right, and have a smart UI designer lay out the screens for you, in my experience the worst thing users ask for is changing positions of some controls, unless they like the app that much that they start with extensions right away. But here the proper analysis comes in handy - your boss is in a good position to demonstrate the increased scope to the customer, and negotiate additional budget.

We use a more or less similar approach, only it's a programmer doing the meetings (one with extensive experience in mapping business processes to software, though). It is our experience that if done right, you get quite stable requirements. The substance of the application doesn't change, most changes are requested only to the UI (larger fonts, switching positions of some controls, reorganization of menus, but nothing really important, requiring important changes to the data structure or to algorithms), and users are happy using it right away. And, due to proper requirements gathering, iterations asked for by the customer are seldom, maybe once every few years. And they are usually cheap - it's really seldom that we have to change things, in most cases we have to add stuff. (Spoeaking of which it is quite impressive to see how persistent a business process can be, if well designed. Gives you a whole new perspective on business dynamics. (Did I mention I like parantheses and a deep call stack?))

Now, I'm pretty sure we wouldn't be able to achieve such economy of iterations if we didn't do proper requirements analysis. We might get away without proper design, for small apps, but I think it would increase our coding effort - individual programmers would need to iterate on code in order to get it integrate properly with other programmers' code.

One thing you must also be aware is that what's a clunky interface for you might a bright, shiny and perfectly usable one for someone else. The adequateness of an interface is not only a matter of using sound UI design principles, but also a matter of the specific field of use and accumulated culture of the users. Somebody having his head stuck into database interfaces for ten years will surely not appreciate a form containing just 20 fields visible at a time - it's too poor for his (acquired) taste. The same, somebody used only to web apps presented with a typical database interface (maybe one in text mode) will potentially puke on the first contact. Getting it right is again a matter of proper requirements analysis - while the customer and the end-user will bever verbalize specific requirements about the user interface, it is (IMO) the job of the person doing the requirements analysis to have an open eye for such aspects as culture and specific field of use too.

However, in terms of business efficiency: how well do you think the process your company uses works. i.e. how good is it at allowing your company to finish projects on time and on budget? Do you think getting to code before the business analyst finishes his work would deliver the same or better results? Because at the end of the day that's what matters.

I posted a much more rude rant against agile methods at http://aflj.wordpress.com/2008/11/12/agile-development-is-mostly-just-hype-imo/. If somebody thinks highjacking this thread has already gone too far, please bash me there (the tone of the post surely favours bashing, IMO).

Flat View: This topic has 18 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic