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)"
Our managers don't GIVE us development specs, or keep changing the specs every 5 minutes so that a formal document is worthless.
Or, in my personal experience, we stick to a formal document for 3/4 of the product then get hit with feature creep for the last 1/4 which makes the product late, buggy, over budget, etc, etc, etc
Sure, I've tried instituting "processes" and management's alwasy keen on the idea. But when push comes to shove, >poof.
The only time management ever stuck with a process was the medical company that, by law, required governmental oversight that demanded process. And you don't want to know how much we skirted process anyway. (Most of the times we built the product first, then wrote the "planning" documentation second.)
In a small team - say 3-8 people, you can get a hell of a lot more done without formal specs. and it is usually exactly what the customer wants.
Of course, this never works in real life because managers want documents to mark the progress against their gannt charts so they always interfere with the "make sure you spec it properly", and the manager on the other team will say "dont do a damn thing until you see a signed off spec"
Shit - its no wonder commercial software costs so much.
You can't expect to wield supreme executive power, just because some watery tart threw a sword at you
Apart from the classic Software Engineering advantages of a proper design document, it can also save you the problems which can arise if the customer and the supplier have different ideas about the eventual product.
I've seen it happen way too often; the expectations of customers can be very unrealistic simply because they have no knowledge about software engineering.
Having a complete design document with two signatures can prevent 'just add this one little feature'-type problems.
When I work by myself or with one or two developers
who I know well and get along with(and talk a lot with) We can get by with practicly no specifications even with a coding which lasts several months.
You can split up the work by writing header files first and that usually does the trick.Obviously this
cuts down on development time.
However I had on several ocasions needed to join in on a project which has been going on for sevral years, and I found it much much easier to start working quickly on the projects with more specs.
I am currently on a project run by a man who is quite anal about specs and standards and documentation, and organized testing. The result is that I spend more time dealing with standards then programing but It greatly increases the quality of the code, it makes the throwing out a week of work for incompatebilty impossible, And perhaps most importantly it makes getting aquainted with a diffrent part of the project very easy.
As for EP, I have seen it work well and I have seen it fail miserably. I have not yet gathered enogh expirience with EP to identify what makes it work.
Me.
P.s I am not a US resident, nor did I study in the US.
But if I look at those that aren't suffering much right now, those doing well, I see that most of the successful U.S. deveopers and shops also specify things out. But, because we don't live and die by the regulation (those being cradle-to-grave parts of much of the world), we can also be more flexible more quickly. And we can prototype from the seat of our pants quickly.
A down side of "flexibility" though is that we often get called "not team players" if we don't instantly cow to the calls from sales and marketing every time a new feature idea pops up. One of my co-workers calls this "chasing butterflies", the lack of focus that results in never finishing anything. That's the downside that leads to bugs and slow development... and failed companies. But many more successful companies, including most of the ones I've been at, have actual product life cycles. There really are two tiers or classes of development companies that way.
The question is, why are there so many undisciplined shops? I think the answer is the easy money of the past. Suddenly we (developers) weren't being managed by engineers and developers, but rather by CFOs, shareholders and sales people. As the crunch continues, I suspect corporate Darwinism will continue and we'll scale back to more methodical practices again.
1. Get an idea and start working on it immediately.
2. Stop work on it to fix a bug, release the bug fix immediately.
3. Work on the idea again, but slightly changed.
4. When about 80% done, switch to new idea or "gotta have" feature.
5. Code like hell on original idea because it was released in its incomplete form and has now killed puppies.
6. Rinse, repeat.
All the while there's very little documentation, most of it being whatever I do.
Great, isn't it? That's how it was. I've taken control and actually have implemented a release schedule and proper bugfix releasing. I've also just gotten a QA guy, things are looking up. The processes before I got here made me wake up at night. Lo and behold, with the new processes, the phones don't ring as much.
Ahh, the joys of a very small company.
I think its more like:
Requirements are what the customer wants.
Specifications are what he's actually going to get
Design is how the analyst thinks it should be done.
There was a little back and forth discussion, but basically the requirements were hammered out in a few days. The development team of about 5 coders took these requirements and over the next 6-8 months we used a "release early, release often" strategy. We called it "Build a little - Test a little", basically we had a GUI designer cranking out do-nothing screens, while the rest filled in the guts one function at a time.
We ended up essentially almost on time and almost on budget. The project was WILDLY successful and still in use 7 years later.
We have been funded now to produce Version 3 of this product. Most of the team has moved on, including the chief architect who drove the implementation philosophy and he's been replaced by someone who has embraced specifications like a baby marmoset clings to it's mother.
Since December, we have done NOTHING but attend meetings and write excruciatingly detailed requirements documents, and crank out UML diagrams. Not a line of code has been written (besides a bit of prototyping).
I'm doing it because I have to. I see a lot of extra labor cost (I estimate at least $250k so far) and I don't think this process has helped us. I think we could have created an entire prototype since December and thrown it all away and been ahead of the game (assuming we'd learned valuable info from our mistakes)
In my experience, RUP seems far better. The customer rarely knows exactly what they want. At best they'll have an idea of what they want it to do and can visualize how they think it might work. So you start with a loose set of requirements, do some quick high-level design, and code it. Then show the customer what you've got. They can identify what is different from what they want and see some of the issues they may not have thought about. This defines some lower level requirements and designs. Repeat this process on a regular basis and you will get good, well-written, and efficiently created software.
I've had nightmares with the Waterfall process. I've had to spend 6 months writing requirements and design docs, formally releasing them, then have 2 weeks left to write the code so the software wasn't nearly as good as it should have (or could have) been. In the end, the requirements and design had some inconsistencies that could not be foreseen until you try to code them.
On another project (that I was not involved in) all of the money went into the requirements and design process and the end software was crap, wasn't user friendly, and didn't get used. But it did meet the requirements.
The problem with writing requirements completely before coding is that you have to basically do the design and coding in your head as you write the requirements, otherwise you can end up with things that are inconsistent. Written language doesn't have to be self-consistent, software does.
On the otherhand, writing software without following any guidance from the customer is definitely worse.