The boss wandered into my office, something obviously on his mind. We had just finished developing a rather complex instrument and my team was hoping for a few weeks to catch up with a mountain of other long-deferred problems.
“Uh, we need you to design a new version of this thing,” he announced.
To do what? Any specs in mind? Requirements? He deflected my questions with a wave of his hand and a vague “make it better and faster, smaller too, with more features.” Minutes later he was gone, off to Europe for a couple of weeks. With that we embarked on yet another development odyssey.
That was in 1975, when the only recognized software development methodology was big-up-front design (BUFD): figure detailed requirements, spend months designing the system, and only then design the hardware and software. In the decade I spent at that company we never used BUFD. Management's needs to see something working now meant we were cranking code long before the nature of the machine was clear.
Frustrated with these and other issues I eventually left and started a consulting company with an old friend. We'd do it right: figure out the customers' needs, create an awesome design, and finally pop out the perfect implementation.
Ah, the naiveté of youth! Turns out our customers didn't want that they wanted something to play with, now, ASAP. People came to us with merely the vaguest outlines of what they wanted.
One outfit with many years experience in industrial controls gave us virtually no functional spec but supplied reams of wiring specifications and rules about how to use explosion-proof enclosures. Specs on features, performance, and user interaction were lame at best. Needless to say we took a financial bath on that project.
Things didn't get much better.
Two years later I was consulting on my own. My first customer had spent a lifetime in the kitchen cabinet business, and wanted a bit of software to automatically design kitchens. That seemed sort of interesting. Since Ralph was a noted industry expert all I had to do was suck his brain dry, create a spec, and crank some code. Yet the rules he gave were habitually wrong, conflicted in complex ways, or were incomplete. Every new prototype invariably produced designs he denounced loudly.
“It's not supposed to do that!” he'd scream, but he could never give a consistent framework for me to work from. Perhaps I wasn't smart enough; God knows I didn't have the patience for this sort of thing and eventually quit.
Decades later the requirements battle hasn't improved. What's different now is that BUFD is the straw man against which all alternative design approaches gets measured. Agile methods like eXtreme Programming are predicated on the impossibility of knowing detailed requirements. They advocate starting the software immediately, before anyone really understands what the system should do. To quote advocate Ron Jeffries “Get a few people together and spend a few minutes sketching out the design. Ten minutes is ideal half an hour should be the most time you spend to do this.”
As an old hand in this industry, I have to acknowledge that the truth behind this statement is that it mirrors the reality of the world. This is much like what too many of us do. XP and other methods simply codify an approach we've used furtively for many years.
But in the firmware industry, where our products might be either safety critical or at least very important to our customers, such a casual technique has to lead to lousy products.
Though BUFD is flawed in many ways, I think the alternatives are, for most embedded systems at least, even more dysfunctional. We need to know what the system will do before cranking code. Design by clairvoyance, waiting for the spirit to enlighten us, or hoping a design will emerge from the code are all routes to disaster.
What's your experience in determining your system's requirements?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .
A long time ago I worked for a big telecoms company in the UK. One day while discussing specification anddesign with an old hand, he picked up one of those Post-It(R) pads – the tiny kind that everyone uses for bookmarks.”Your design should fit one one of those”, he proclaimed. My manager today takes the same attitude, except he'd like touse smaller Post-Its.
I think Jack has touched a very valid point.In theory before we crank out code,the requirements and design should beclear.But in real life they are often vague and contradictory.
In joint ventures good requirements, as well as heeding those requirements are critical. In one failed jointventure, one of the two partners used a modified portable handset grade transciver, when an aircraft grade transcieverwas asked for by the other partner. A big gap in required performance forced cancelation of the program.
Granted, my experience doesn't go as far back as Jack's but I have learned something about requirements:1. Customers rarely can tell you what they want without seeing it.2. Customers usually can tell you what they don't want when they see it.Lesson: It is better to show the “wrong” deliverable sooner than the “right” deliverable later.
Most people are fairly impatient and abstract thinkers by default. Quickly giving them what they say theyexpect, often produces a lot of feedback (generally negative if not explicative), but it forces them to be morethoughtful about what it is they really need. Granted, this may not be a viable solution for many.
“But that's the way it's always been done!” We all say that we need detailed specs for each design but I haverarely received such a document from a customer.
One of my current customers handed me a CDROM of old, MSDOS based Turbo C code, and said “Convert this to Windows”. Thespec was the old code.
First, I had to get them used to the concept that we needed to design the GUI, to take advantage of the Windowsenvironment. I used VB to prototype the UI “on-the-fly”. It worked pretty well and helped them get used to the new lookand feel.
Needless to say, it was a rough few months. As I plowed through the old code, I found errors and bugs in the oldproduct! I have now provided documentation for the new product, in case they are ever asked for a spec. The majorproblem with this process is feature enrichment. Since there was no solid spec to begin with, it is very difficult toend the development phase – just add one more feature, please.
– Michael Weisner
As the saying goes: Good, Fast, Cheap. Pick at most two.
You might get only one!!
– Tom Watson
Whatever the approach in such a situation, it should be made eminently clear to the customer how vague the”specification” is and how equally non-specific the first cut will be. This should, of course, be mutually understoodup-front and most definitely affect the way you get paid.
– Bruce Scherzinger
Most of my career has been devoted to implementing highly specified, safety-critical systems, so I'm sure theywouldn't be considered “typical” – however my lone experience with telecomms software was almost the opposite of Tony's.I was brought in to “bang out” the “no-hardware demo” version of the configuration S/W for a DSL access multiplexer inVB6 (the REAL code was in Java/CORBA and the developers were so busy writing code in the 3 years they'd been working onit that they didn't hsve time to write ANY specs so I was told to go in the lab and write “demo code” of the samecomplexity [110 or so setup screens] that MIMICKED the operation of whatever I saw working)! The story was that theywanted to “simulate” their package to customers without having to bring along any real hardware…the REAL story was thatthe actual code could take several MINUTES just to initialize and present a responsive setup screen!! Needless to say Idoubt that the real product ever went anywhere in the marketplace… something they MIGHT have known if they'd ever satdown and written a performance spec to start with! But when I asked about that they of course insisted that “by the timea spec was prepared and ready our market window would have closed several months earlier”…!
Charles' comments are spot on. The trick is to be able to show the customer something early, which is wheresimulation comes into its own. Show them a mock up, let them take it to pieces, fix it so they like it, then crank thehandle on the real code.
– Paul Tiplady
It seems the real problem is customers want cheap products that do amazing things right now. They have this unsatiable appetite for technology. We need to nip this thing in the bud before it gets out of control! I don't think the current administration is doing enough to manage demand for technology.
– Jack Crack
Most software projects must balance a trade-off between Good, Fast, and Cheap, as Tom mentioned earlier. It is not as cut anddried as adopting two and ignoring the other. Requirements are a must in some form or another. Same with design,implemetation, and test. It is just a matter of how much time and effort we are willing and able to spend with each of thosegoals, and how acceptable the trade-off's are for the project at hand. Projects vary all over the map within this tri-goalarena; it is a Project Management determination as to what combinational approach best fits the needs of the project. We, assoftware developers, must be flexible enough in mind and skill set to understand and adapt to project goals, whatever they maybe, as well as be adept with managing Project Management expectations.
– Chuck Barkley
I once had a manager put a piece of paper down on my desk and say “There is the final schematic. Let me know when the softwareis ready.” Turns out the schematic WAS the spec. I figured out how to read the inputs, switch the outputs, etc., and the crankedout the code. A few weeks later I saw an assembled board being packaged up. I played dumb and asked one of the sales guys whatit does. He started describing one of the control modes. Since no one had told me that before, obviously it didn't do that.
Maybe we need to change our job descriptions. I don't think that we will ever see it become a trend that customers will deliverwonderful complete specs months in advance of the software being due. I think we need to accept the fact that our initialconcept of what our job is, is wrong. Our job isn't coding to spec. Our job is creating the spec and then designing andimplementing the code. The best software leads that I see are the ones that know how to tell the project what they want, theyare the management-business-technical bridges. Without them, the most brilliant customer with the most brilliant programmer isgoing to go no where.
This editorial is the story of my life! With the products I design (high-performance ignition systems & rlated racingelectronics) one of the biggest problems is that those who are requesting the design don't have a good idea as to what is andisn't possible. What I try to do is ask them, “What would you LIKE?”, then take some time to see which features I can implement,then go back and negotiate the final result. We just recently went through this process, and surprisingly, we wewre able to geta pretty good set of specs that look as if they are very do-able. However, many times I've been asked to add a feature where Iknow that the person asking doesn't realize how much work it would entail. Anither question I've learned to ask is, “How many ofthese do you expect to sell?” Typically, we do relatively low volume items (severla hundred to several thousand annually) sothere are times I have to let them know that the development time will overwhelm the expected profit if they have to have all ofthe bells & whistles.
– Dave Telling
Sometime between, say, the construction of the pyramids in Egypt, and the 19th century, the building construction industry bifurcated into two expertise domains: design and construction. Architects designed, and contractors built. And in order for contractors to know what the architects had in mind, several powerful information exchange mechanisms evolved. Architects built models (e.g.: Michelangelo's 1547 model in wood of St. Peter's, presented to the Pope), and produced working drawings. The builders then used the working drawings to accomplish the construction. No competent builder would accept incomplete or incorrect working drawings. To do so would risk bankruptcy.
We aren't quite so disciplined in the construction of software. Though the scope of work in a large project may take years to complete, the work product is mostly invisible, unlike a skyscraper. When software construction is underway, our clients see people sitting at workstations. There are no big holes in the ground, no noisy, heavy equipment, no piles of materials. Lines of code, even if there are millions of them, aren't tangible to our clients. Hence, many projects are cancelled, or are finished “late” (as defined by the original, deeply-flawed estimate), and “over-budget”. The software industry needs to develop a discipline of design and construction. Until that happens, software development will largely remain, in the words of a former manager who was a hardware guy, “a thankless job.”
I agree with the collective experience presented here: thorough, complete, and unambiguous requirements from day onecan practically be considered a white unicorn for engineers. But I also believe that there is much to be said for modern designmethodologies that are predicated on this fact. What all of you have either described or purported is that a prototypingmethodology is often the most natural. It is easier to mine requirements from a customer that has something tangible to use as abasis for discussion. Our customers are usually not engineers (or usually not of our own respective discipline) and lack theanalytical process and theorem-proving skills that we do. (for that matter, how many of you could have drawn up the exactblueprint of your home prior to seeing it) To extend the XP philosophy – code a little, test a little, show a little. It's beenmy experience that hardware/electrical engineers tend to voice more adverse critism to this model in theory because, more sothan software, hardware in hand cost more in terms of hard, “real” dollars when thrown away. But, in practice, what else canyou do?
The other thing to keep in mind, as experience has almost infallibly proved to me, is that customers are more opt to understandthe need for better requirements and work “for” you if you can communicate the tangible cost of bad, up-front specification andthe cost of change curve. This is becoming even more true in organizations implementing process management/improvementmethodologies like Six Sigma, where operational people are becoming better trained at understanding the consequences of a badprocess. Once again, I don't think this communication is something that we as engineers have been very successful at doing inthe past. It's also the reason why we often find ourselves envious when Marty in accounting finds it so easy to get the boss tore-evaluate how his department functions; Marty convinced his boss with the $1.5 million dollars they'd be saving by doing theforms the right way.
In my experience simulations are not the best idea to show the customer. Once they see this simulation, theyautomatically start to glow and consider the job done.You try and try to explain that this is just some VC++ code on a GHz PC but by then is a losing battle.Weeks later when you deliver your 1st sample on actual HW with limited functionality at best, the calls start! “But we saw itworking weeks ago!!!”
I remember working at a company that made phone equipment. The local division made militaryphone switches. Now , because it was a military job, the design was documented with requirements every wayyou could think of – and yet the development process was a nightmare. This was a large design -approximately 20 8080 cpu based boards as sub processors and an in-house designed 16 bit processor (spreadover 4 18″ * 24″ PCB's).
All development was done in assembler, and while the tools for the 8080's were good (BSO Assembler and IntelMDS stations) the 16 bit Master was a bunch of in-house 'tools'. Mostly the engineers would patch the codeand then every two weeks write all the patches into the source and then start a day long assemble and linkprocess (we're talking 400,000 lines of assembler).
The 16 bit CPU was an old design, and the company wanted to get one more product out of it before going tonew technology. The result was a disaster in terms of delivery time and product operation. This system wasdesigned to run 24 hrs a day, 365 a year – I never saw it run more than a weekend at a time – when therewere no calls being placed. If you started making calls the system died even quicker. I spent about 9months there and found so many things wrong that I quit because I didn't want to work in a company thatcould design such a hunk of junk.
So while I think that a good set of requirements is a great foundation, you can still design junk to lay ontop of it if you're not careful.
By the way, this system was eventually installed here in the US as the communications system for Norad andCanada. I sometimes still shudder thinking about that…
– Tom Mazowiesky