Slashdot Mirror
MIT Studies Software Development Processes
IsoQuantic writes "A new MIT study (pdf) looked at SW development processes around the world. One striking difference that the researchers found for U.S. developers is the relatively small use of specifications before development begins. I can already hear my EP-zealot colleague chuckling in the cube next to me. (sigh)"
Specs!? Specs!? I don't need no stinking specificiations!
I used to work in a very loose development shop. The only specifications that were ever written down were protocol specs - and even those were often "documented" in the form of a header file.
I found some parts of this method usefull in that the specs were often written as as pseudo-code comments, and the actual code would be filled in later.
However, eventually the development pool grew, and we got a few folks who couldn't follow this method, and we lost several weeks of work. After that standardized specificiation paperwork was produced for every project from that point on.
Perhaps it's a lesson everyone will eventually learn. Perhaps I'm being an idiot.
Kinetic stupidity has a new brand leader: Allen Zadr.
In my software engineering class, my teacher vehemently states that Requirements are the Enemy of Design. You need to have an idea of what you are doing for the project, but you honestly cannot know how much space it will take, how fast it will be, etc. Its sheer folly. And who isnt to say that a customer may realize that they want it differently as the process is going along. Design is dynamic, always growing and changing. And the Open Source Community best represents this, because a project never ends, but continues to develop in a myriad of directions.
je suis parce que j'aime
when working in R&D, the specs is always a step behind the cutting edge...
I have learned the same lesson. I hate bureaucracy as much as the next guy, but I really like having a good specification. Most of the programming I do is related to various forms of messaging, and having a detailed spec containing
/var/log/myapp.log' :-)
a) The purpose of the integration (business concepts)
b) The protocol
c) Examples. Lots of examples
makes the whole process a lot easier.
Especially the business concepts are important. They allow me to foresee where changes and extensions may occur, and I then put more work into those parts.
If you're fortunate enough to have a good project leader, use him to communicate with the other parts involved and make him also document all the changes in the protocol. That will save you a lot of time on the phone and quite a few 'tail -f
And of all the praise they lavish on Japan and Indian the conclusion brings it back to reality with:
Politicus
Quite frankly this study is worthless. As a business owner, here is what I really want to know. Who is best at producing a product that meets my customer's needs the quickest and cheapest, has great uptime and the fewest bugs. I could give a rats ass how you did it, as long as it meets the above and it is documented.
-Subotai
"The only way to catch tiger cubs is to go into the tiger's den."
When you use specification - you are making the "customer" the deisgn engineer.
I highly doubt the "customer" is going to deisgn great software.
for example.
A thousand customers could say I need a tool that lets me input the various factors of my budget and look at what the sums will be.
But how many could say - I need a program with a grid of flexible cells which can hold a value or a formula?
AIK
The presence of detailed development specifications is arguably directly related to the size of a design team.
If your development team is two guys sitting next to each other all day long, there isn't much need for very detailed specs or a set structure. You tell then what your project must have, and they deliver (if they're good).
On the other hand, the larger the team, the more structure is required; you don't want one person breaking what another person took four weeks to complete.
I think in the US, the relative lack of specs is probably because most US firms are in one location where the developers are in close proximity, making communcation quite easy (you don't even have to take your eyes off of your screen to yell over a cubicle).
It would have been nice if they had included smaller companies in their sample. Probably just as well that they didn't, though, because I suspect those would make the US numbers look even worse.
Slashdot - News for Herds. Stuff that Splatters.
There's a difference between a spec and a design..
SPec documents are the "what" the customer wants.
Design documents are the "how"...
Slashdot is like Playboy: I read it for the articles
As a gov't employee, I understand first-hand how frustrating it can be to get useful, realistic requirements from our customers (other gov't folks). And I'll also agree that unnecessary beaurocracy can baloon development cost.
But unless you maintain good communication with your customers, you're bound to get it wrong. If you suspect they either don't really know what they're asking for, it's better to clarify that with them than to decide for yourselves what they really want.
"Ask not what your country can do for you." --John F. Kennedy
When people say Specifications - they mean software code written in a language managers can understand.
(For What?)
The only perfect language for software specs is an unambiguated, testable, logical language.
The end result of this logical posativism IS software languages.
Software languages existed before the computer, and unambiguous processes could be described unambiguously only be using these unambiguous languages.
So I suggest the software IS the specification - and its testable.
If you write confusing software - what makes anyone think you can write specification which are any less confusing?
(Suggestion - delete major important detail and make it look simple - when in reality it is merely incomplete.)
AIK
Maybe that's the problem. Too many times we worry about creating the "grid of flexible cells" and forget that the real user just wants to "input the various factors". There's a good usability lesson to be learned here...
Still - it is only what the customer THINKS he wants on day one with far less experience in computer techniques.
Customer says he want a report - but in reality he want to understand his business.
An OLAP server can help him understand his business, a crystal report can start him down a long road of report modifications which in the end will lead him to 1. an unmanagable pile of confusing reports or, b. an OLAP cube.
The design process is to understand the need of the customer - not have the customer specify how or what the solution will be.
If you provide the solution the customer specifies - you will be run out of business when he reads the next business journal anout how to do omething better.
You had beter know what he is going to read next if you intend on being a solution provider for very long.
AIK
So many articles on software development concentrate and talking about what procedures to use (and how to get people to buy into using them, etc. etc.) Very few of them give any good data on the outcomes of using those procedures. Typically we get b-school type "case studies," anecdotes, and proof by repeated assertion.
Typical logic: PREMISE: It is good for software to be of high quality, in time, and under budget. ERGO, do thing my way. COROLLARY: It is important to use an indentation setting of three spaces on everyone's editor, and draw diagrams using the symbology provided in this plastic template.
Here's my first-order analysis.
All over the world, software development uses significantly different formal processes and practices. Yet, to a first approximation, there are no obvious, huge, systematic differences in the quality, cost, or timeliness of software produced in any country versus any other country. Therefore, to a first approximation, the formal process and practices don't matter.
Good people, backed by good management, with a good understanding of requirements and sufficient time and resources, can develop software successfully. Using the waterfall method, Extreme Programming, or no methodology. Mediocre people, given bad management, and inadequate time and resources will fail. The brand name of the methodology that is asserted to be being used has an effect so small it is lost in the noise.
In my software engineering class, my teacher vehemently states that Requirements are the Enemy of Design.
Unfortunately, a lot of college professors are out of touch with reality. Software development is such a diverse area that you really can't generalize.
For example, I worked for a long time in embedded firmware and digital signal processing, both on mega- and micro-projects. You need to design to requirements for these. There can be creativity in how you impelment a design, but the bottom line is the spec. If you don't design to the spec, the satellite falls out of the sky.
Currently, I am working in multimedia, and we don't really use specs. We have high-level goals, but even these are fuzzy. Here, requirements are more of a hindrance, but we still have to draw the line in the sand for some things.
(S(SKK)(SKK))(S(SKK)(SKK))
Good software engineering requires iterative and incremental approach with constant feedback from the customer. (Personally I ascribe to an approach similar to the Unified Software Process.) If a US shop did this they'd guarantee long employment as the iterations continue throughout the life of the product. Of course, this also results in more rubust software with better ability to react to the demands of the customer.
As it stands developers are just getting a crack team of developers and throwing them into a pit with a page of "specifications" and whenever the management needs to talk to them they send down a bucket.
If that's all it takes to develop software no wonder all the jobs are getting sent to India. Even they can handle that!
Good engineering practices would have prevented offshoring because the software you get from properly engineered software is more stable and closer to the customers needs and because the level of feedback required for proper development would make the communications barrier an unacceptable hindrance.
Bullet proof specs. are very hard to write.
:-)
I spent many years as a low level civil servant; so none of what I am telling about is my fault
To make a pile of money on a government contract, do the following:
1 - Bid on the contract EXACTLY as the tender is written (no matter how stupid the tender is). This is what the government will stick you with. If somebody else bids on the tender the way it should be and comes in cheaper that's ok. The government will stick them with the stupid specs in the tender and they will lose money! They go out of business and you now have one less competitor. **Include a generous hourly rate for 'extras'. Make sure that 'extras' are cost plus.
2 - Build the project EXACTLY as tendered and bid.
3 - (This is the important step) Discover that the project will not work as designed and tendered.
4 - Fix the project at public expense. This is the part where you apply the 'extras'.
5 - Profit! Note the lack of question marks at any stage of this process.
Specs are fine but they are no replacement for wisdom. If you need to cya then use specs. Otherwise, take them for what they're worth.
This has been my experience as well. I've worked as a software developer on dozens of consulting projects in North America and Western Europe, and the US managers prefer to work from "intuition" and "feel" rather than the rigorously specified requirements and design that the Europeans insist upon.
I personally believe that there are merits and drawbacks to both approaches and that the ideal is somewhere between formal and informal approaches.
The informal, intuitive approach can result in a deliverable that is a much closer fit to the actual needs of the client - not just what they think they want or what they can express in words. A good informal manager circulates through the entire target organization from management, to accounting, to the IT department, to the users, and sometimes even to the client's own customers. Through a process of information osmosis, the manager constructs a feel of what the deliverable really needs to be and directs the team accordingly. Obviously, this approach works best when the project manager is damn good (sharp *and* experienced) and the development team is small and works well together. The main drawback, of course, is a tendency to chaotic development as things are written and rewritten to hit a moving target.
The formal approach is reliable, predicatable, and safe. Maybe what you deliver will not be a perfect match for the unspoken requirements that inevitably surface during the project lifecycle, but at least you have a better chance of delivering *something*.
I wonder, however, with the growing pool of cheap outsourced labor, if the paint-by-numbers formal software approach is really the best answer for the US going forward. If a project is specified in sufficient detail, then anyone can do the development. Perhaps the intuitive, informal approach is the only competitive advantage a US team can offer going forward - a dream team of software magicians rather than a clockwork team of software engineers.
... I understand first-hand how frustrating it can be to get useful, realistic requirements from our customers...
I'm not sure if you meant this to sound the way it does, but you've pointed out my pet peeve:
The customer is not the proper person to write the specs. Specs must be written by a skilled analyst who can observe and communicate with the customers in a manner to determine what is required.
I've seen too many projects go down the drain because they were completely useless. They were completely useless because the specs described a system that was useless to the customer. Because the specs were written by the customer. Because the project manager simply asked the customer "what do you want this system to do?"
Customers are usually qualified to do their job, not to write specs for software system. It's the project manager's responsibilty to hire a qualified requirements gatherer (a lot of times a usability engineer is good for this) who will spend a lot of time with the customer, interviewing them, observing them work with their current methods, etc. There is much more to this than collecting specs written by the customer and putting them in a standard format.
Requirements written by the right person will make a project much more successful, requirements written by the wrong person will definitely ruin the project.
Most of the programming I do is related to various forms of messaging, and having a detailed spec containing
a) The purpose of the integration (business concepts)
b) The protocol
c) Examples. Lots of examples
I have to second this. There is no reason that specs or design docs have to always descend to the level of pseudocode for every module. However, interfaces have to be specified. They won't be written in stone. When there is a need to change them, the spec will provide a clear way to talk about what is missing and how it can be changed. If you don't have that, you quickly find that different people have different views of the interfaces. If you are lucky, one is a superset of the other. If you are unlucky, they intersect incompletely.
Made in USA much earlier :-)
You completely missed the point. No one is forcing anything on to the customer. But quite simply, if you have EVER worked in the software industry designing custom systems for customers, you will know that the customer generally doesn't know what they want exactly. They have a vague idea and assume that you have the same idea they do in your head.
The requirements process is where you get your specifications from the customer about what he or she wants. Design is a completely seperate stage. The requirements are something you both agree on, but its not just something the customer sends to you. You give them feedback about the requirements. Perhaps they are contradictory, perhaps there are better ways to do things. This part is crucial in that the more time you put into this, the more information you will fish out of the customer, and you'll be more confident that you and they will know what the software is supposed to exactly do.
The golden rule in software engineering is the requirements are going to change. You just have to accept it. Why do requirements change? Well, usually its because the customer finally realizes that what they got and what they actually wanted were two different things. And thus you make the necessary changes until the next time they come back looking for you...
How many times have you downloaded a program think it has everything you want, until you use it and then realize theres something more it needs?
Think about something like Mozilla. It's be a sufficient browser for a while now. But once people got it, started using it, they thought to themselves "Now I need tabs!". And thus the evolution of software...
Not only that.
Usually you try to understand what the client wants, and design the system to provide it. Then you write the detailed specs of *how* you do it, what kind of data you use, etc. Then you present all that to the customer, and have him sign it. It makes things a lot easier as clients sometimes tend to ask for changes in the middle of the development process, when all design has already been done, and half the code has been writtem.
"Luck is my middle name," said Rincewind, indistinctly. "Mind you, my first name is Bad." -- Terry Pratchett
I think it's true, spec writing does often fall by the wayside. However, I think it's far more prevalent at small companies, and non-tech-oriented companies that nevertheless have engineers. It's often a money or time thing, because it takes a lot of time and effort to pre-document things before developing them, and small companies don't often have such luxury. But there is also a lot of laziness involved. I don't know many engineers who like documenting things at all, much less weeks or months before they get to knock out even a line of code. Given the chance, they will generally blow off docs and start hacking.
I think this has very little to do with extreme programming, and everything to do with motivation (or lack thereof). Though I think this phenomenon has one thing in common with EP, in absolute seriousness - laziness with regard to writing specifications.
This series of comments by AIK is profound. Please get off your apple-pie-and-motherhood methodology soapboxes and pay attention.
Customers do NOT know what they want. Anyone who thinks that they do, hasn't spent enough time architecting software.
What AIK is saying is that you have to dig deeper than the customer requirements. You have to understand the space. You have to look at competitive products. You have to anticipate unstated needs. You should ask, "When I'm all done, and everything is working perfectly, what changes will the customer want IMMEDIATELY?"
I can't stand people who listen for five minutes and start to write "use cases" right away. That works for some dumbass web site, maybe, but certainly not for any involved product design.
Architects need to plot an intercept strategy several YEARS in the future. That's how you build successful software. When the customer puts his Phase N requirements out for bid, and all your competitors run for the hills, your design has anticipated his needs. You've built metatables instead of tables. You've used OLAP where you could have sleazed by with an RDBMS. And so on.
Great thread.
I think Christopher Alexander sums it up beautiful in his Patterns book, in the 'Gradual stiffening of design' pattern.
He observes that only in-experienced craftpeople plan out things down to the minute detail to begin with. This causes them to get lost in the details and not able to recover from an problems during the building stage.
Experienced people all employ processes that may start out with a rough high level design, but the detailed design only gets determined as the construction process matures.
The idea is that a more fluid design allows you to both absorb errors or any problems or new insights that may occur during the actual build process.
The same thing applies for software engineering.
There is a nice balance to be found somewhere between the bondage-and-discipline approach and the XP style design-as-you-go. The type and size of the project also have to be taken into account.
Where I now work I typically build everything in one of the following tools, ASP.NET, VB.NET and MS SQL Server. At the company before that it was all in Lotus Notes/Domino slowly migrating to ASP. And before that it was all Java.
Why did I choose those tools? The answer is, I didn't. I never got a choice of what to use. I had to use what the company already had in place.
I know very well that ASP.NET is not the best place to build a workflow application. But managers have already picked their favorite technology, even if they don't understand them.
In smaller companies the IT manager used to be the network admin. Guess how much network admins know about software design and languages. Try nothing!
So until they start promoting trained software developers to management this problem with persist.
Whoa, whoa, whoa, whoa, whoa, whoa, whoa, whoa, whoa, whoa, whoa, whoa. Lois, this isn't my Batman glass. - Peter
"The golden rule in software engineering is the requirements are going to change. You just have to accept it. Why do requirements change? Well, usually its because the customer finally realizes that what they got and what they actually wanted were two different things. And thus you make the necessary changes until the next time they come back looking for you..."
This is why the people who do this kind of work need to have some of the same skillset as salespeople, with a leaning towards the technical arts. Salespeople need to identify the customers needs, and wants and give a clear voice to them. The tech part comes in when being able to figure out what is possible, and what's unrealistic. The diplomatic skills is in telling the customer the bad news without antagonizing them. People with such cross-disciplinary skills are rare, and the result is mirrored in the product, and the process further down the line. GIGO as it were, do it right the first time and the rest falls into place a lot easier.
OK, I don't really know how much of Indian work is for US companies ;-)
Honestly, most Dev shops don't have "code librarians" anymore. When they did - this was the person who would make sure that code didn't get duplicated. If a current function could do what needed to be done with very few changes, so be it.
What happened where I was - some people who were not well trained in the code base started re-creating a large number of functions that we already had, and did so in an otherwise incompatible way. Yes, this should have been caught by the team lead... Yes, this should have been caught by their boss -- However, it could have been avoided had they been given a very specific specification of what these folks were expected to do.
I don't care how new the programmer, few of us like having someone over our shoulders - so, most of us assumed that they were each learning about the project as a whole, as opposed to digging in and seeing how to impress everyone with quick output. Human nature prevails again.
Kinetic stupidity has a new brand leader: Allen Zadr.
If the customer has a million expections, but your Lead or Project Manager has not told the customer what to expect from their current "official" requirements, then you will have a disappointed customer. However, if you let the customer know, right from the start that the project will do exactly what they ask, and no more - then "extras" that were designed in through savvy programming, code re-use - or interface standarization, etc. will now be beyond the customer's expectations.
On the other hand, when a customer says, I want it to be like Excel, the Project Manager's first words should be, "why can't you use Excel?" - as opposed to "Sure, what about Excel do you want us to emulate?".
Kinetic stupidity has a new brand leader: Allen Zadr.
"I estimate that this will cause another 3 weeks of delay for this product. If you like I can finish off working on what we have so that you can start using the software and we can get some feedback on real usage. We can implement these new features after that"
Offshore developers are less invested in their users. They rely formal spec's and adherance to "Best Practices" to defend themselves, very politely, of course, against user dissatisfaction with the app as originally (mis) spec'd. No more dollars, sorry... but no recoding...
Name an elegant app that was spec'd right from the start... No? Name any number of awkward apps that meet their spec's but are unusable... No problem!
US users are independent, demanding and coddled. They know what they said they wanted, but now that they see it on the screen what they really want is...RECODING!
These are just the expeiences of a pragmatic old US developer...
"Knowing everything doesn't help..."