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)"
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/
Then you can consider a rigid design - which means you can consider outsourcing - but I ask, what novel piece of software was invented in a developing country?
I strongly disagree with that statement. I work in an software consulting company in India and I have seen examples of great pieces of software being designed in India. Mind you, these were not your run of the mill software projects, these were complex projects which solved complex business problems at the very heart of the clients business. Just because you don't see the applications or they are not visible does not mean they haven't been designed and developed in a developing country.
Take for example FlexCube which is banking software developed and designed in India. Now this software has been voted the best a banking software for two consecutive years and is deployed in major banks around the world. (No I don't work for the company that developed this piece of software)
It is not the easy money. As a programmer who was around before the "bubble", there were many many undisciplined shops before, during and after, at least from where I sit.
The problem is that the business and sales types that run these companies, by and large, dont understand software development, and dont want to understand it. Further, they do not listen to the development managers that they hire, and often overrule them, using their own misunderstanding to guide them.
emt 377 emt 4
Requirements are both good and necessary, but they do require something that I've noticed a severe lack of amongst programmers: Discipline. The discipline to develop preliminary functional models, perform up front what-if analysis, do the FMEA's and maybe a few MSC models for the interfaces. Then map it all back into what the customer says they want and walk them though it. Sound like a lot of work? It is. It also requires a modest amount of negotiating skill and the willingness to both educate the customer, when necessary, and the determination to stick to your guns when you know you are right, always.
I can hire truckloads of happy little coders who don't have a clue about requirements, and then train them (which I often have to do), but I treasure the software engineer who knows and understands the value of requirements, knows what the term "traceability" means, and can effectively translate the customer's needs and wants into a set of models and requirements definitions that accurately and adequately capture the design objectives.
And, yes, things do change during the course of a project, and new things are discovered. That's why the requirements specification is a "live" document subject to continuous review, and there are things called "derived requirements".
And, just one other thing to consider. If you assume a unit cost of defect removal of one (1) at the coding stage, then it's been shown that finding and removing a defect at the requirements stage only costs around .2! That's right. It gets better. Over half of all errors in SW are introduced at the requirements stage. Not doing any requirements? Then brace yourself for some long and agonizing test and debug sessions. Don't believe me? Take a look at this report:
NIST study on software defects
It's big, but chock full of good information.
For an introduction to requirements engineering, this is one of my favorite books:
Davis' book on software requirements techniques
And lastly, here are some links for the curious:
FMEA/FMECA info
Good article on DO-178B
Some more info on DO-178B
A paper on requirements traceability
Info on SDL and MSC
Then again, I guess there are some folks who enjoy whacking away at their software, growing it "incrementally" (no relation to the formal model, BTW), and spending their time at the back end of the project listening to the customer scream about missed delivery dates while they frantically do the compile-test-debug dance over and over. For myself, I'd rather see it just work with a minimum of verification hassle from the outset and then get on with my life.