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)"
Outsourcing these jobs should fix all these problems.
I Am My Own Worst Enemy
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.)
And of all the praise they lavish on Japan and Indian the conclusion brings it back to reality with:
Politicus
Shouldn't that be colleagues? :)
I prefer a void in conversation to a vacuous one.
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."
Hah! I'm halfway through my current project, as indicated by the constantly shrinking schedule, and I haven't even had to have ANY specifications or requirements to get to this point!
However, they HAVE managed to change the name of the project on me at least three times, and our last two-hour meeting was consumed by a lively debate on what to call a particular form, so it's not like these critical planning issues are being neglected.
Requirements that are too rigid are bad. But so too are requirements that are too loose. You can't sit down at a computer to program without some idea of what result you want to end up at. Often proof-of-concept programs are helpful, but all too often management sees a demo that appears 80% feature complete and thinks the project is almost done. It leads to unrealistic expectations.
The best trick I've ever seen for setting project goals is to sit developers down with business users or the end users of the product and have them observe work in action. This understanding can go a long way when a developer is back in the 'cube' for long hours of coding. Domain knowledge is critical to a developer. Otherwise you end up with some trully epic program that bears little to no pracitcal value.
Requirements should be clear, reviewed often, and adjusted as necessary. Which requires a good project manager to really pull off succesfully.
All in all programming is really a mixture of a lot of aspects and any one not in balance with the others will skew the results. Sometimes you'll still get something usefull, but more often then not the results are hideous. And management will always blame the developers and developers will always blame management, with the only difference being the developers don't have the ability to can management.
Sir, there is a dragon outside with an armful of armor. He's inquiring if we offer free refills.
Having worked in America, UK and India, I can certainly relate to the findings of the report. Here are some of my personal experiences:
:-)
:-)
- In America, they are in a tearing hurry to produce a prototype/model/proof of concept, which of course forms the basis of initial release ("it works, doesn't it? so why re-write it?")
- Gathering requirements is a pain in the wrong end - I've seen all sorts of instances - CFO disagreeing with CTO and re-writing everything, PO Manager introducing something new that CFO promptly over-rules. At the end of the allocated gatherings period you have a hash of what each stakeholder at the company wants. Needless to say, there is a lot of fun in ensuing months - Most American customers do not like to spend time on discussing/analysing progress or answering questions during the development (yes, I agree they shouldn't crop but, but most times they do).
- As a natural progression, the aspirations change over time. By the time it's written and demo-ed they want it to do 10 different things and pipe-up about how they had "already" mentioned they wanted this cool new feature. The signed copy of requirements specifications sure helps
- In Britain though, they pore over every single email the PM/Team Lead sends. Tremendous emphasis at every single aspect ("We are bloody payin you for this, aren't we?")
In India though, life is Sh*t. The documentation team, the process team and the internal audit teams sort of join hands to drown you in sh*tload of paperwork. It's good to have processes, but IMHO, they just get carried away and want copious detailed documents about everything and anything...Unless they develop tools to automate and regulate the processes, it is gruelling and something no-one looks forward to...err, except the audit team
http://efil.blogspot.com/
Space and Time requirements ("The system shall reply to queries in no more than .2 seconds and write no more than 650 megabytes per day to the log")are non-functional requirements. Other requirements ("The control system shall have an option to backup the log to tape") are functional requirements.
Simply throwing out all requirements because non-functional requirements are difficult to estimate is absurd. That's why you make requirements but you make them flexible and reasonable. Of course, you can say that the customer doesn't know what they want and even if they do they can't explain it exactly. That's why you iterate through the process.
A Software Requirements Specification document may even be a legally binding document for a development team.
To say that requirements are an enemy of design is incomplete - there is a fine line between requirements that are 'too rigid' and 'nonexistant'. Somewhere there is a nice balance between requirements that are harsh and strict and requirements that are so loose they might as well not exist.
If you get the customer involved, iterate through the requirements (entire software lifecycle) process, and make reasonable requirements, you'll be much better off. Personally, I would rather have in writing what the system should do than just have some kind of vague idea.
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.
Seriously not trolling.
Care to point out a tiny sample of "most" Open Source that follows this norm?
In the interest of being taken seriously I will point out a few that I know of that seem rather well thought out:
fltk
FOX
gcc
Oh yeah, here
and others
You were modded informative yet I see nothing informative in your post. Perhaps because I have contributed to some of these projects and I am jaded? Perhaps because more work gets done in these projects than the corporate arena of closed source that I used to work in and I might be close minded and missing your point? It's a possiblity but I will try to become openminded in case I missed the informative part of your post.
BSD is designed. Linux is grown. C++ libs
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.
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.
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...