After reading Ovid's specify,specify,specify i first had the urge to laugh because it has been for me that way ever I started the developer's job. But then began wondering why is it that you always end up whit either incomplete or completely wrong specs? Because they don't know.

In my time as a developer no customer / project coordinator or whatever has had any clue what he / she really wanted. So you had to come up with a draft first, then specs changed, you had to rewrite 80% of the code (mostly) or with that changing specs in mind you will write a lot of unnecessary overhead (which it turns out to be in the end).So are we doomed like Sysiphos to recode all of our works?

I don't think so. We just need to talk more to our customers and give them more time to influence the project. That is also a caveat. We have to make it clear to the customers that in order to satisfy exactly their needs they also will have to invest time in the project instead of leaning back in that siwel chair and waiting for results.

But this might be a long way and we are just at the beginning of that road (I always wanted to say that :-)) My boss calls in for another project's review. I have the strange feeling that the specs will change...

Yours,
C-Keen

  • Comment on They don't specify because they don't know what they want

Replies are listed 'Best First'.
Re: They don't specify because they don't know what they want
by Sherlock (Deacon) on Oct 02, 2001 at 20:03 UTC
    This is a very common problem when creating software systems. More often than not, the customer comes to you with a problem they want solved. They usually have a rough idea of what they want in order to solve the problem, but that rough idea is usually a lot rougher than we'd (as developers) like.

    There are a number of things that can be done to counter this, and you've already hit on a number of them, such as giving the customer more time to influence the project and also to get them more invloved in the project. The second concept, getting the customer involved, is VERY important. If the customer sits back and simply waits for results (and you allow them to), 99% of the time, you're going to give them a final project that isn't what they expected and probably doesn't do what they wanted it to. Obviously, this is not a good situation. You need to actively get the customer involved. Bother them. Question them. Keep hacking at the problem until both of you know exactly what the system is supposed to do. If you do a good job of this, what you eventually hand over to the customer will be exactly what they expected and they'll be much happier with the project.

    So how do you keep the customer involved? Like I said, keep questioning them. Try to identify anything about the project that you don't know for certain - anything from how something should be displayed on the screen to complicated business rules. Believe me, your customers like to feel like they know their business (don't you like to feel like you know how to write software?) and they'll be more than happy to talk to you about how their business runs. This is a good way to get the customer involved right away.

    Another good method of getting the customer involved and verifying concepts is to create a rapid prototype. This is a rough mock-up of the final project that doesn't do a whole lot, but it lays out the basic interface and "look and feel" of the final project. Showing this to the customer can help identify and resolve issues with future functionality and interface early in the development process. Of course, rapid prototyping isn't without problems of its own - look here for a fairly extensive node on the subject.

    Of course, one danger with this whole process is to allow the customer to alter the projet requirements throughout the entire process. At some point, you need to be able to "sign off" the requirements and tell the customer that this is what you'll be getting. At that point, the requirements have been worked out to the point where the customer will get what he/she needs from the project and you will be able to complete it on time. Once the customer signs off, the project need to go into some form of "change control." By that, I mean that the customer should have very limited ability to change the project. Only absolutely necessary changes should be made (something that would cause the project to fail that had been overlooked). Why must this be done? If you allow the customer to keep adding new features as the project advances, you'll run into the horrible beast known as scope creep. Soon, you'll end up with a project so large that you'll be unable to maintain it or add to it. This is a very nasty situation to get into. After that sign-off, any new features that the customer wants should go into a later release of the software or some such thing.

    So I've babbled quite a while about this topic. It really all comes down to one thing that you've already hit on - customers seldom know what it is that they really want. There are ways to get around this (which I've been trying to outline here), but the most important thing to do is to know, ahead of time, that your customer is clueless. Not that they don't know business, but they don't necessarily know your business. It is our job, as develoers, to teach them as much about our business as we need to learn from them about theirs.

    - Sherlock

    Skepticism is the source of knowledge as much as knowledge is the source of skepticism.
[reply]
(Ovid) Re: They don't specify because they don't know what they want
by Ovid (Cardinal) on Oct 02, 2001 at 20:55 UTC

    After reading tilly's response to my post, I realized that I sounded a bit more dogmatic about the situation than I had intended. I see that I have a habit of doing that when I post too quickly :( Basically, there are two ways that I prefer to develop a project.

    1. Well defined specifications are handed to me.

      The benefits of this should be obvious.

    2. The customer doesn't have well-defined specifications.

      This is all-too-familiar, unfortunately. When this happens, I prefer to develop while working hand-in-hand with my customer. I tell them that I'll accept loose specifications so long as they can provide me with a single point of contact within their organization whose word is law.

    On the second point, I go to that person when I have questions and when that person answers in writing (phone calls for discussion, but I'll still send a confirmation email), I know that I can implement their response. They may have to run to other people to get the response, but those other people had better not be calling me! What invariably happens, otherwise, is that I have to take direction from multiple people and when things go wrong, I take the blame.

    With the single point of contact, you wind up with one person who really know what's going on and is less likely to come up with the boneheaded "design everything in Flash5" type decisions. Further, when someone says I didn't do my job, I point to the email or, better yet, the discussion board and say "see, this is exactly what you asked for".

    Frankly, even with well-defined specs, I prefer to work closely with a single point of contact who knows their business and isn't too far removed from actually using the product requested. Otherwise, I have discovered in the software world that one of three things happen:

    1. The developer produces a product that suits the customers needs.
    2. The developer produces a product that is not what the customer asked for.
    3. The developer produces exactly what the customer asked for, but its virtually useless for the customer.

    It's that last scenario that gives me nightmares. The pointy-haired boss (PHB) at Acme Corp. gives me well-defined specifications, but he never bothered to ask his data-entry people what they needed. Know what happens if the product is useless? The PHB blames it on me anyway. Sigh.

    Cheers,
    Ovid

    Vote for paco!

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
Re (tilly) 1: They don't specify because they don't know what they want
by tilly (Archbishop) on Oct 02, 2001 at 20:53 UTC
    First of all in that thread I already addressed the issue you talked about at Re (tilly) 1: Specify, Specify, Specify, and can heartily recommend clemburg's comments at Re: Specify, Specify, Specify.

    However I would like to make a short, related note.

    Frequently a piece of software will have 3 or more stakeholders. In that case it is both possible and unfortunately likely to run into a situation where no matter what otion you choose, there will be another that most of the stakeholders think is better.

    Consider well the following situation. Suppose there are three options, and three stakeholders. Let us call the options A, B, and C. Now suppose that the stakeholders rank the options like this:

    1. A, B, then C
    2. B, C, then A
    3. C, A, then B
    Now what will you choose? A? 2/3 of them think that C is better. C? 2/3 of them think that B is better. B? 2/3 of them prefer A!

    Good luck getting a consistent picture of what "they" want...

[reply]
Re: They don't specify because they don't know what they want
by Maclir (Curate) on Oct 02, 2001 at 21:32 UTC
    Ahhhh! The clients don't know what they want. So all of us ace coders jump in, knock a proof of concept prototype, and interate this design with the confused client. This is a job for:

    Super-Analyst

    Yes, faster than a speeding celeron, able to leap tall piles of specifications at a single bound . . .

    Ok, seriously folks. There is a role in the development process, called a business analyst. This person does not (or should not) cut code. They have the ability to rapidly understand the underlying business processes and requirements of the users / clients, they know the common problems and "gotchas" that can plague poorly designed systems, and they can turn users' hazy concepts into clear, unambiguous specifications that programmers can then develop good systems from.

    An analyst is not a senior programmer, they aren't the gun C++ / Java / Perl coder that can churn out top quality code in their sleep. An analyst is the bridge between the business experts and the developers, able to speak the languages of both groups, and make sure that everyone has a clear understanding of the same set of requirements. An analysts two chief weapons are the ability to write clear, well structured documents and the ability to quickly grasp new business environments and problems (and a fanatical devotion to the pope ... out three chief weapons are -- whoops, wrong story.)

    Seriously, all the discussion recently about program specifications, and people's grips about having to work where there are poorly specified requirements indicates one common problem - the lack of a good business analyst working on the project.

    And I jus happen to know where there is a highly experience one looking for work . . . here!

[reply]
(jeffa) Re: They don't specify because they don't know what they want
by jeffa (Bishop) on Oct 02, 2001 at 21:28 UTC
    Amen! They really don't know.

    But, remember - the specs will always change. Always.

    The important thing to do is make sure the customer SIGNS off a valid spec sheet - so that when rep A from a company says "This should be blue"and you change to blue, and then rep B says "This should be red" and you change to red, and then rep A comes back and says "Why didn't you make the change the blue" - you have some kind of proof to justify your fee.

    Having to do work is not a bad thing - not getting paid for that work is a bad thing.

    We can't escape having to work, otherwise we wouldn't need jobs. Now the lottery, however . . . ;)

    jeffa

[reply]
Re: They don't specify because they don't know what they want
by pixel (Scribe) on Oct 02, 2001 at 20:00 UTC
    We just need to talk more to our customers and give them more time to influence the project. That is also a caveat. We have to make it clear to the customers that in order to satisfy exactly their needs they also will have to invest time in the project instead of leaning back in that siwel chair and waiting for results.

    Sounds a lot like Extreme Programming to me :)

    Blessed Be
    The Pixel

[reply]
      There's nothing "Extreme" about it. This is simply a case of solid software engineering principles. Whether you adhere to the guidelines of Extreme Programming or not, you should be taking the fact that you customer seldomly knows what he/she wants into account.

      - Sherlock

      Update: Sorry if this seems too much like a rant, but I'm currently dealing with a situation at work where someone made an assumption and passed it along to me as fact and now I need to fix everything while we're already into the testing phase. If this would have been resolved with the customer to begin with, this wouldn't have been nearly as much work. Silly me, I should have verified.

      Skepticism is the source of knowledge as much as knowledge is the source of skepticism.
[reply]
Re: They don't specify because they don't know what they want
by earthboundmisfit (Chaplain) on Oct 04, 2001 at 00:34 UTC
    Ya know, all of this is really good discussion, all the way back to the Meditation that started it all, but the one thing no one has talked about so far is what happens to the process on a smaller scale.

    I work for a small company of 50 employees. I'm the sole Web developer and Perl programmer and the only "customers" I have to worry about at this point are the people I work with on a daily basis. I develop intranet applications to replace the largely antiquated ones that have been around since 1988 (written in some God awful DOS based language that no one has ever heard of).

    I play the role of code slinger, program analyst, quality assurance specialist and net nanny, on any given day. For the most part, my co-workers don't even know what's possible, forget about what's needed or wanted. I find the only way to produce something that actually helps them is to sit down, sometimes for hours on end, and just talk and watch them perform tasks.

    I ask questions. They ask questions. We talk about technology and our business process in pared down terms (on both sides) and only through this deliberate contact do I get a clear sense of what they want and need.

    And this isn't a bad thing. It's just part of my job, and honestly it's far from the part I like least. I end up understanding the business side of my company much better and they end up understanding at least on some level exactly what the technology is about and can do for them. Maybe its a by product of a small company but to ask my peers to go off and write down what they want would send the wrong message. I'd rather involve them in the process even if it means throwing away some code that heads down a wrong alley.

    $.02

[reply]

Back to Meditations