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.
Outsourcing these jobs should fix all these problems.
I Am My Own Worst Enemy
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...
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.)
MIT used to be so creative... what happened...
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
Interestingly, Cusumano and Selby observed a decade ago that Microsoft programmers in general did not write detailed designs, but went straight from a functional specification to coding in order to save time and not waste effort writing specs for features that teams might later delete [9, 14].
Cue a lot of M$-related jokes and M$ bashing!
http://efil.blogspot.com/
specifications are for people who are told what to.
This really shouldn't be a suprise to anyone who reads slashdot. Every week or so we see a story about Company X exporting IT jobs to India. Where do you think they get their specs from?
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
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.
This mostly comes from the bottom up, and not the top down, simply because there are more minds at the bottom than at the top. And as long as those control freaks at the top of foreign developer outfits continue to overspecify their requirements, the US will continue to lead the field. (And thanks, Boss!)
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.
1) Developers (developers, developers)
2) No specs
3) ???
4) Product!
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
well now that I've read the conclusion, the author seems to agree that Bender is from India. :)
page 20 conclusion
"It is important to remember, as well, that no Indian or Japanese company has yet to make any real global mark in widely-recognized software innovation, which has long been the province of U.S. and a few European software firms."
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).
I work for a company where time to market is crucial we literally don't have time to get the product fully spec'ed and design.....most times the developed product is not even close what the "invisager" imagined...but the luxury of having a fully spec/designed... I find that the best thing to "at least have" is a high level list of requirements/use cases even...
Open Source projects do handle specification control well. However, most open source projects are written by developers for developers. It's very easy to determine the functions for a piece of software that you are going to use yourself or someone who does a job similar to yours is going to use. The exception to this are projects that are competing against a closed source product - such as Mozilla, GIMP and Open Office. However, in many cases, they tend to join together the better features of their closed source rivals and remove a few annoyances.
If you're building software for a specific business use (ie, managing insurance claims) or a specific technological use (ie, controlling emissions on a car), you have to understand the environment into which you're introducing your software. In those cases, specifications dictate how the software system will interact with the other systems (business or technological).
I'd like to see a "fuck" (or it's non-english equivalent) count from source developed around the world and compare the differences in that. anyone have something like this?
I also reply below your current threshold.
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.
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/
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
Kinetic stupidity has a new brand leader: Allen Zadr.
I don't know where you work. I don't want to know where you work. It sounds like a scary place like Initech. Is your boss Mr. Lumberg by any chance??
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.
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
While I'm not disagreeing that U.S. Developers may not spend enough time in design before starting to build, I don't think that the blame always lies with the developers. My personal experience has been that, for every missing design doc or spec, there is someone in sales who shaved a week off of the estimate the developers gave them for building the solution. If MIT is studying the Software Development Processes, maybe Harvard should do a study on the Software Development Sales process, and on why US companies have developed the mentality that it is ok to give developers less time than they need to complete development, and even better to base the timeline of a project on developers working 65 hour weeks when they know damn well that they are salaried employees and thus get no overtime.
What about the twinkie? - Dr. Peter Venkman, PHD
eventually the development pool grew, and we got a few folks who couldn't follow this method...
Aren't you really saying that the specs have to handle the "least common denominator"? In other words, they have to be understood by the dumbest person in the group.
Now think about it and I'll bet you produced more and better code with the smaller group!
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.
So, crack open a cold one and check out my double nested for-loop ollie nose-grind, dude!!
And who says we're zealots?! ;-)
RRR
Stuff that matters: circuitbreakers, vacuum-cleaners coffee makers, calculators generators, matching salt+pepper shakers
Happened to me at school, so I speak from experience :). That was my best semester at school - I used to wait eagerly for the project submission deadlines so I could go on an "EP date".
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Well, I started this new job six months ago as a developer, I was stunned to see that there was nearly 0 development and two out of probably 10 developers using Version control (excluding myself of course). It has taken me this long to push though a massive whitepaper on how to write software. Software specifications are damned important! Without them you are in the shit, because if you make a cock up or near a dead line things can get really bad, really fast. Probably proves why there is so much crap software out there!
With Aegis the baseline code "always" works; it has to pass all the build tests to become baseline.
You can't add a new feature without first defining a test for it to pass, you can't fix a bug without defining a test that the old baseline failed and the new baseline passes.
So marketing can walk up and say "release now" or "add these features" and you can do either. But you can't "release these features now" because the system won't let you.
When marketing say "release now" they can only have the bits that work. And when they say "add these features" they can only get those features when they work.
Sam
blog.sam.liddicott.com
I've always hated commenting/documenting my code especially since I feel as though I can keep it all in my head. However, when one begins to work in in large projects with teams it is imperative to have a focussed design to make sure everyone is on the same page, but loose enough for change. A LOT of documentation however is always helpful. Document, Document, Document!!! Learn from other's mistakes...I learned this the hard way.
I get so damn sick of hearing about processes and procedures. Slashdot is one of my favorite was of getting rid of frustrations, especially when the frustrations are related to processes and procedures. Imagine my dismay when the new article was about processes...ugh
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...
Damn, where have they been hiding after school then?
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Lack of specifications is the only thing U.S. programmers have going for them. When there's no specs, the developers have to think and must understand the business requirements, which is difficult to outsource. If someone ever figures out how to automagically create detailed specs, then all our jobs are going overseas. No specs is fine with me.
Yipee! Now all of our problems will be solved because MIT is on the job.
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
Maybe the lack of specs is why people offshore more, they want more definition, they want more quality elements defined up front and don't want the project to run out of control based on trusting IT.
Given a choice between a nice spec, and a bloke from IT who says "trust me I'll talk to you lots"...
Which is a business person going to chose ?
Engineers specify, DIYers just knock it together.
An Eye for an Eye will make the whole world blind - Gandhi
After spending a day designing a hardware interface last week, a coworker and myself were informed from the CTO that we need to learn to "exercise the evolutionary programming model, meaning don't ever develop specs." The problem with that philosophy is blatently obvious in all the products we sell. They have 1) a real weak foundation making the addition of features neigh impossible, 2) a lack of modularization making team work neigh impossible, and 3) nobody knows when the freakin' thing is done. Because of these issues, whenever we hire a new programmer they want to rewrite the software. I can't say that I blame them. Needless to say, I'm a huge fan of taking at least 20% of the development time for the design cycle if not more.
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.
Anyone else find it odd that the first page of this supposed 'new' study was marked June 2003? And the second page said it's version 3.1.
Which goes to show -- even if we had specifications for these things, we're just going to gloss over the details, and do whatever the hell we want, anyway. People don't read what's sitting in front of them, unless it's on some blog, it seems. If it were really important, they'd have made a TV show out of it.
[and those of you with moderator points get to vote if you think sarcasm is funny -- you can select 'troll' to vote no, 'funny' to vote yes. 'overrated' if you'd like to abstain, and 'insightful' if you read the first line, and are just trying to burn your moderator points]
Build it, and they will come^Hplain.
I think there needs to be a clear demarcation between specifications and documentation. I always think of the specs as to what is supposed to happen, and the documentation of what actually happened. Well written code (for the most part) is self-documenting. Specs will almost always be out of touch with the actual implemented code because Specs usually represent a static attempt to solve a dynamic problem. Code comments are usually an evolving snapshot of what's going on ...(use the source?)
I thought requirement documents are "what the customer wants" ?
We can't tell cos we can't see the source.
Government of the people, by corporate executives, for corporate profits.
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.
Project Manager: "Ok team, start coding the system now, I'll go and find out what the customer wants..."
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.
Bullshit.
You can know all of this, and pretty accurately, too.
It sounds like your teacher just isn't very good at developing software, because a lot of organizations develop software all the time on schedule and on budget. Before I got into consulting, I worked for a few orgs that had entire processes and metrics to do project estimation - and it was pretty damn accurate for programs up to and including those that had millions and millions of lines of code.
It sounds like your teacher is proof of the "those that can't do, teach" adage...
Requirements may be bad, especially in making sure that you can keep the Design flexable, but I think they are very much needed.
The Requirements don't have to specify memory and space, but they SHOULD specify functionality. Don't forget the requirements produced by a programmer would (and should) be different from those produced by a manager.
When you are working to provide a customer (boss/division/consumer) with a product (program/library/etc.) you need a benchmark of how to know if you succeeded. Even if its just to make sure they don't come back to bite you in the butt, by claiming that they needed required something totally different.
If you are trying to design a complex piece of code, a specification is a must. It can evolve (and it probably WILL and SHOULD), but it needs to be there.
A good specification can also be the foundation for the program/projects Documentation. Everything that is listed in the Specification, should be in the Documentation also (and usually quite a bit more also). This makes your job easier in the long run, both in terms of handing off a project to other individuals to use/support/maintain, and in terms of your own ability to use/support/maintain it.
Lack of a Specification only works if there is a small cohesive program group, without a high rate of turnover, who will also support the product. Even then, this will only work untill a project gets big enough.
I also dispute that Open Source projects have no Requirements given. The "Project Leader" usually has some specific goals in mind, and other contibutions that either coexist or enhance that goal that other people contribute are usually included. True, the Requirements are not formally laid out (usually), but there is usually only a very small group of people working on any one piece, and there usually are no deadlines. Things are allowed to percolate and progress as they will (take a look at how many Open Source projects stall out also).
This type of thinking might work in OS and Reseach, but aint gonna cut it in Buisness.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Aren't you counfounding requirements with specification? You can have a requirements specification and a design specification.
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.
http://darin.csua.org/survey.mp3
I made it with TextAloudMp3+AT&T Natural Voices; I highly recommend both.
Please mirror. I won't keep the file up for long.
Maybe I'm misunderstanding your intent here but I'd say the release-early-release-often is a huge strength of open source development.
By showing all the warts, all the problems and solutions as they are worked on, those of us who are chasing the latest nightly CVS release get to help out by bug triaging, raising problem reports and commenting on the very latest change pretty much as it happens. This stops stupid decisions, breakages and irritations early before they are ingrained.
However, for the average user, that is too much. But just because development is pushing on at a rapid rate doesn't mean that the user has to play catch up. This is where the packagers of applications play their part - Mandrake/Debian/RedHat/etc - by providing a tested stable base. If you want the ultimate in stability, you would probably look at Debian Sarge or RHEL. You can pick a more intermediate solution which is closer to the latest releases with Mandrake numbered releases, closer still to the edge with Mandrake community /Fedore core 1 or almost at the bleeding edge with Cooker or Redhat Fedora 2 test 3.
So really, stability of releases is available now. The only scary thing here is that you have a Choice.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
If you have a customer paying millions of dollars for a product, and you deliver X when he paid for Y, your lame "code is specs" isn't about to keep you employed and able to pay your mortgage.
And who is this projects "customer"? If it's consulting or contract work, your product isn't the code you write, it's the hours you bill.
Or in a large organization you could just be part of someone who gets graded on how big his "empire" has gotten and you're just being given make-work.
What the customer wants and what he needs are different things too.. as illustrated here (no idea where it came originally from, if you have the proper credits, please post them)
Managers also want specs so they can outsource the work. I'd say this whole topic bodes well for US developers wanting to limit outsourcing. Indians can't work on a project without a good spec.
REFUSE making specs if you want to keep your job in the US and not India!
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.
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)
Now many times have I been asked to quote on a project with out having any specs.
Some people just don't know what they want just think that they want it. However, they always know "that is a quick and simple job, shouldn't cost too much"
Maybe someone is actually using Evolutionary Programming (not)?
-- Nothing unusual happened today
7. Add 20% (I'm almost there...)
8. Add 20% (Just another two weeks...)
9. Add 20% (Darn these last minute bugs...)
10. Add 20% (Testing takes time, you know...)
11. Add 20% (They want "web based" now...)
12....
Vote in November. You won't regret it.
I don't know about you, but I'm tired of Academia treating Software Development as an unwanted stepchild. Case in point, Software Engineering was only recently added (within the last few years) as a required course at a local university. It replaced compiler design.
Not that compiler design doesn't have its merits (it definately does), but for an Undergraduate CIS major, which is most likely going to benefit them having a job? Knowing how to build a compiler, or knowing how to design robust commercial applications?
-DB
This is so arrogant, it's unbelievable. You pretend you know better than your customers what THEY want?
If my customer reads a report right now, setting up OLAP and wasting months of it is not worth a single red cent to him.
The design process it to elicit proper specifications from your customer. If he says he wants a report, feel free to mention OLAP and explain the benefits. If he insists on a report, you better give him one - no matter what you think is best for him.
If you don't provide the solution the customer specifies, you're defrauding him, plain and simple. You stay in business by establishing a relationship, not by employing a "Mommy knows best!" attitude.
The "Market" produces software requirements to meet a common need. I have found in practice that the quality and basic outline of those needs (requirements) are best handled by domain specialists, i.e., accountant, economist, manufacture, ecologist, neurobiologist... And that it is in the best interest of domain specialists to produce a comprehensive set of requirements (model) that meets their need. With software requirements in hand, it's up to me, the development team, to design and implement to those requirements however I see fit. The development team must work along side the domain specialist to workout details and compromises. In my opinion the best tool for doing this is the prototype.
0. Outsourcing to india generates/requires lots of paperwork
1. Trees must be harvested to provide more paper
2. Rainforests have trees...
So I conclude that: Outsourcing to india is destroying the rainforests!
I once had the privelage of having the task of modifying some open-source code written by mit students... They believed their coding skills were so superior, they didn't need any comments.
10 separate Java files, written without structure, all 500+ lines, and not one damn comment.
They were also extremely uncooperative in answering questions... Its a shame this experience won't make it into their study...
You make a big assumption, that this paper covers.
with a good understanding of requirements
How do you know the requirements if they aren't clearly specified?
Made in USA much earlier :-)
A quality team can deliver quality software, even under bad circumstances. A non-quality team will _never_ deliver quality software, even when the circumstances are otherwise perfect.
Of course, acknowledging that would be financially painful to some bosses...
It partly depends on what you require to be in the spec and what state of completeness it has to be in before you start coding. I like my specs to be clear on external protocols. They don't have to tell me how to accomplish something inside the box I'm developing for. I was hired because I know that, or I know where to learn it. But I want a clear statement of what my box talks to and the language it speaks.
Over the course of the project, I'm going to propose all kinds of additions and clarifications to the spec. I do that sort of thing. I want a spec that goes through stages during development. Don't write the code without a draft spec. Finishing development requires prelimary approval of the final spec. In between those milestones, the spec is open to decreasing amounts of change as time goes on.
My customers don't know what they want. They don't really understand how their own business works and they feel lost because as their business is growing they lose track of the knowledge that was very easy to keep up with when their company only had 20 people.
It depends on your software and your client base, I guess. When I program for hire it tends to be CRM and HR packages for small businesses that have outgrown Quicken, so I guess it's understandable that I see a lot of confused people who honestly just don't understand their own company anymore.
But at least in my case, my customers really don't know what they want because they haven't yet figured out what they know and what they need to know about their own business; to some extent I can help them with that but generally I just point them to some management consulting firms.
All's true that is mistrusted
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
Understand the need. Write a specification and get agreement on it - only include must haves. Design from that. Create prototypes for EVERY module that is challenging/new/creative. write/test/debug code.
Documentation occurs throughout the project. Make part of the software text file if at all possible. Also make part of an on line help file if possible.
Then rewrite it all when you are done cause once the user has a working version, their "needs" undergo a radical change. Always.
On one project, the only thing everyone could agree on was that it was to be a batch process done overnight so it didn't matter how long it took. I thew in every option anyone wanted, making the end product so popular that they wanted to use it in real time, not batch overnight; so "But can you just make it faster?"
"Sure with a complete rewrite."
Spec is a vague term. If you need to be clear, say whether you mean a specification of the requirements, or a specification of some aspect of design.
As a System Test Engineer, I especially liked this part of the summary
One thing most people don't realize is that 99% of the time, only a small percentage of a program actually gets executed. Much of a program is error checking or handling of unusual events and doesn't get executed if the customer uses the program the way the programmer intended. The only reason that most commercial software is usable at all is because of this. So of course, testing and integration has a negative impact on development time.
Most software companies know this and develop software to be "good enough" since being anywhere near bug-free before shipping the first version requires too much time and effort. Software companies are "gambling" that the bugs that are left aren't bad enough to sour their customers on the product. IMHO, American companies are generally much bigger risk takers than foreign companies. This leads to either a spectacular success or a catastrophic failure
I would like to see the U.S. government start to punish software companies that take large risks with investors capital. I believe a lot of companies die because of poor implementation and not necessarily because of a poor idea. I can't think of anything easier to screw up then software development and it has been considered just an ordinary risk of running a business. I worked for a software company that was run by a man that, from what I saw, didn't give a hoot whether the software worked or not. As long as the IPO produced a lot of money he was happy.
There are many ways to reduce the risk of producing a worthless software program, including certifying programmers, code reuse, and more testing. I know most people don't want to invite the government to enact more regulations but the software industry doesn't seem to be regulating itself. There is a huge crisis brewing on the horizon and nothing seems to be getting better. If the millions lost on government computer systems, like the IRS modernization, isn't enough, we have the potential for a Microsoft virus to wipeout millions of users data.
"Meaningless!, Meaningless!" says the Teacher. "Utterly meaningless!"
As a programmer's experience grows, the specifications at the highest level are typically user driven while at the lower function and subroutine level the specifications arise from experience of optimal and flexible interfacing.
There is a plateau of user-visible features that are naturally expected and are implemented as fully as possible. Then there are smart features that are implemented as far as budgets allow.
What may be helpful is a document that outlines various levels of features at the user-visible level so that a measure of software feature richness can be made. Aside from this I don't support taking enormous amounts of time to thrash out specifications before coding. Software should evolve from experience gained through usage, and features should be anticipated in new systems based on feature additions made in past projects.
Software development has really advanced away from specifications due to the speed of computers. Developers don't have to sit around as much waiting for strange states to occur, and as a result can learn programming much quicker by implementing more features and debugging more bugs per unit time.
Know your pads. One time pad: good for cryptography. Two timing pad: where to take your mistress.
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...
Innovation comes from imagination, not specification...
I looked through the report somewhat quickly, but I did not see any mention of the peculiar practice of sticking developers into small, noisy cubicles, with cheap, eye-straining fluorescent lighting, and then expecting them to foucs and produce top-quailty software.
I was walking around where I'm currently consulting, and I noticed that everybody had a set of headphones, and it just struck me as odd that software development should require specialized head gear.
Java is the blue pill
Choose the red pill
Then you are on the wrong site. Try Forbes.com.
Fixed-price is a much better billing scheme for programming, in my experience. Rather than telling the customer "I charge $75/hour of work", I say "this CRM package will cost you $1200". If I go over time, sucks to be me. If I go under time, that's great for me.
Now, the trick with fixed-price is it doesn't work if the customer is involved in the development, because invariably he will want different interfaces, new features, etc; it's best for software that can have pretty specific and rigid requirements. The other side of that is you always have to educate your customer that A) his initial requirements and B) his subsequent changes to those requirements have consequences. Your fixed-price agreement has to include provisions for the customer to change the requirements with the result of renegotiating the total price (or, some shady people go t&m at that point, and make money hand over fist).
All's true that is mistrusted
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
We produce the documents, which are then ignored by the business person.
Those business persons dont want to talk to you as a development manager about how to specify the project, they want you to just go produce the darned thing, and get it right the first time. And dont bug him / her / it or his / her's / it's staff.
I dont know how many times business has told me something like "that only happens on rare occasions". Like I dont have to account for it. Never mind if I dont, that business person will be first in my face about how I could overlook something so important.
No, offshoring is about the money. The business can have all the definition they want. The specs are usually, as I understand it, not produced offshore.
emt 377 emt 4
Funny that they should mention that, being that Abelson & Sussman from MIT's own CS courses (available via video lecture make the comments that programmers who have to go through a planning phase before they program aren't real programmers. It looks like MIT made most of the programmers who have no respect for the software development cycle.
We were incredibly sensitive when dealing with products that involved peoples' life/health. As engineers, we were very ethical about that. Informally, there was a "line" where you absolutely adhered to process. More accurately, you have a core algorithm that the scientists R&D'd and you don't screw around with that. But the further away from that algorithm you were, the more likely that it would be adjusted to meet budget, time, resource constraints, etc.
.02 cents)
The problem with "process" was that it didn't take into account a creative factor. Basically, you'd have development plan section A, B and then C is where a miracle occurs and then you get D (profit). But the government (and its process) wants you to document specifically what you're going to do BEFORE you know how to do it. So basically you "sketch" out what you're going to do. "I'm going to store this data in X database with Y format". But then when you start implementing it, you discover that the database tables are wrong. So you change them, but you don't have time to update the documentation... Then you realize that a database is overkill and you can get by with a set of updated XML files and oh wouldn't it be great if you could HTTP to the unit and view these files on the fly. Oh wait, nevermind, we won't even keep the XML files on the unit, they'll be uploaded to a central location and stored in a database... You chain enough of these events together in a do-it-yesterday fashion and documentation gets further and further behind so that it doesn't even represent what you're currently doing. Now, this can only happen if your particular development is significantly isolated or you can keep the team notified informally (say about 10-20 people which is what we usually had). Try doing this with a larger group, or with an integral code piece and you'll get strung up by the developers.
(but that's my
The method I found the easiest is first writting a bad version of the product - adhoc design by developers, no optimization attempts, components "integrate" by reading each other's text files, no NLS support and so on - and getting it to run just enough to see where it would fail to fulfill customer requirements even if wasn't so buggy.
Then you start again with an empty source tree and write another version. This time people know exactly what the application is supposed to do, what kind of services other components need from this one and which areas are likely to cause problems and need to be explicitely designed.
Both of which are sometimes very different from what they say they want and/or need. That's part of the reason why overreliance on written formal specifications is a fatal mistake in development.
I think that formula for proper amount of specifications, and process in general, is easy to summarize: You should use as little of both as possible, but not less. (saying originally attribute d to some great mind, maybe mr. Einstein, but it's applicable in wide variety of situations).
Anytime you see a requirement with the word "no" or "not" - you should either re-write the requirement or run away fast as you can and blame someone else. Negative requirements are theoretically impossible to prove.
IE - the system shall not take more than 10 seconds to process the records in the system. Hmm - for those of you that have seen requirements in contracts, do you see a law suite?
Software engineering was a requirement for CS at my college, Loyola College in Maryland (small but good CS dept), in the 80's... WTF is going on at the McCollege near you??
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
When specfications are turned into an overly formal process, the spec process becomes a time-sucking industry in itself. I have seen cases where some "Spec Police" count how many slots are filled in on the forms, while most of the time it is stuff that is obvious and redundant for the module. Plus, a one-size-fits-all spec form does not work well. Different kinds of projects need different approaches. For example, a report-centric project does not need a "database change results" section because reports usually don't change the database contents. Ideally it is a give-and-take process, not Slot Policing that works best.
Table-ized A.I.
What really made my eyes bug out in this study were the defect numbers. They are claiming a low of .005 per KSLOC - which is five defects per million lines of code! The high was fifty defects per million lines of code. There only explanation of this statistic is that Defects = number of defects reported in the twelve months following implementation / KSLOC. I can only surmise that after implementation means after delivery. Still, this is better than my experience would lead me to suspect by a factor of about a hundred.
In my experience, one of the most significant and under-recognized challenges in development is the selection of the right tools, operating environment and languages in which to develop/deploy an application.
.ASP, and Perl that really should have been using something different based on the demands of the process.
These days, your typical American developer has a narrow stable of technology that he uses. He often doesn't stop to examine whether or not the application being designed is best suited for the environment in which he plans to build it.
I'm probably going to get flamed for this, but I believe we now have "vanity languages" and platforms that are driven more by marketing than fitness for a particular purpose. In the last several years I've seen lots of programs written in stuff like Java, Cold Fusion,
I would suspect a significant share of development disasters are due to the people involved choosing the wrong tools and then making things ten times harder for themselves later on.
Find a new software engineering teacher fast 'cause you're right now you're giving your money to a crackpot. Your teacher's argument is like those people who say "you honestly cannot know whether the Sun will rise in the East tomorrow" because that is a future event. You can't really know any future event until it happens, but you can learn how to have confidence whether it will or not.
When learning software engineering you are supposed to be learning things like which space/speed/etc. characteristics are offered by which designs and how to approximately predict that for new designs (try a "theory of computation" course sometime). Knowing those things, you can select designs appropriate to the requirements.
The phrase out here in the real world where you actually have customers is "Design to Cost".
While I would not classify this article as 'worthless', I would say that it is of only limited value. There are too many questions left unanswered and too many caveats with regards to interpreting the results. I commend the effort but they did not succeed in providing great insight into the issue. With this baseline investigation done, other studies can attempt to find greater distinctions.
One of the aspects that I feel was left unaddressed is how well the development models that the Indian/Japanese houses are using work at US/European houses that use those same models (and vice-versa). Is there a socio-cultural aspect that allows these models to work better in those societies? I did not see a classification for software performed for government institutions, which often have their own cryptic methodology and requirements.
jroop
That's great for small projects. Try finding a shared workspace that can hold the development team for a 15 million lines-of-code product.
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.
n ce
Sorry, but your teacher is an idiot. He isn't teaching software engineering then, he is teaching programming. HUGE difference.
Requirements are not required. What? You heard me. There is a concept called FURPS+ that you can use to classify your requirements.
Functionality
Usability
Reliability
Performa
Supportability
The "+" in FURPS+ reminds you to include such requirements as:
design constraints
implementation requirements
interface requirements
physical requirements.
But here is what I meant by my first statement - you don't have to have requirements for all of these categories. You don't HAVE to have performance requirements - but you have to consider whether you do or not. Same goes for the other categories.
And this is just the tip of the iceberg when it comes to requirements. I love how people always complain that software engineering doesn't get the respect that other types of engineering get, but they don't really want to do engineering. They just want to program. There is such a huge difference between software engineering and coding. And I am not saying that everything needs to be engineered - but you can't just write off requirements as unnecessary for all software projects.
How on earth can a software engineering professor think that they are useless? No, you don't know how fast something will go - but you had damn well better know if it is required to be "X fast" or be "Y big" BEFORE you start building it. That is the point of requirements, to state what is (duh) REQUIRED of the system before you build it. When you are done building it, you can test to see if it actually meets the requirements. Otherwise, you are just playing grab-ass in the dark.
My beliefs do not require that you agree with them.
Gotta say... that's hit the nail on the head and driven it right through the other side of the board.
Well said!
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
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.
If you are wasting months on an OLAP cube that is your problem.
I implemented OLAP cube with an excell frontend embbedded in a webpage such that all users in a multistate company could view the OLAP live from the website - and it took LESS time than any crystal report - and it was precisly what the company had been hinting at for years - only they didn't understand what it was they wanted.
Yes - I'm arrogant if it means anything to you.
AIK
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.
if your design breaks when changed in the middle - these is a hell of a chance it will break in tthe end - when more changes are necessatry.
If I was the customer - I woulld ask for half the project - then chhanges the specs just to see how flexible the design was and whether or not it is future proof.
Speaking of which - I think the military should do more of this - it should test suppliers to see how fast the can react to design needs generated in real time - because in war people die for evey day your chain of useless executive paper stamper takes to "approve" a design change.
AIK
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.
Using standards in your daily programming (regardless of if they are required or not) gives you practice for when you get work at a shop that does requires standards.
However, it certainly is more advantagous from a job security viewpoint to specifically not use standards. If they don't have you to decipher the code, then they will be up the creek.
Not requiring standards shows the inexperience of management. Every mature development house has been burnt by people unintentially/intentionally not using standards... that's why they require them.
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
I believe there was an experimental language in the 1970's where the specification was the code.
You actually compiled the specification. Any changes made to the spec also changed the code at the same time.
Does anyone recall the name of that language?
I own a small software shop and do basically all the programming, have for 10+ years. Over the years we've had people join/depart to fill various rolls. Having someone do QA on a regular basis is probably the biggest help to the company. Instead of having the customer do QA (still happens) and going into panic mode constantly disrupting trains of thought, etc. The QA guy and I work together in a calm fashion to get everything worked out. It's great! I go into panic attacks when my business partner talks about getting rid of the QA guy to save money.
Our spec.s are usually bullets lists, which are perfectly fine. I think having QA early and all the time is much more important than spec.s. The QA guys, if they are good, are much more likely to point out if a feature is stupid, broken or is awesome.
My $.02
"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.
The lack of specs will keep the American programmer employeed. It might not be proper Software engineering but who cares if I still have a job. An Indian can read a use case of the specs and architect an elegate solution or I can sit next to the business owner and throw something together in VB and ASP. Also let the projects get out of scope. More hours for support and maintence. It is the undisciplined nature of business that will stop this outsourcing of tech jobs.
OK, I don't really know how much of Indian work is for US companies ;-)
No, your specs ARE your requirements. It is called an SRS (Software Requirements Specification). It is not just what the customer wants. It states, in no uncertain terms, what your system is to accomplish. An SRS may even state how it is to be done if there is a necessary constaint for such. A design is not an opinion. It states, again in no uncertain terms, how the system is to be implemented. Deviate from either and you may lose the contract for failing to create a system that does what it is suppose to.
Anonymous Cowards suck.
I've actually found that I can get rid of 90% of feature requests just by asking them to put the request in writing. Often these simple requests aren't even worth the effort of the requester to spend five minutes describing it. (You spending five minutes describing it for them doesn't count!) Now if they write it down, well, maybe it really is worth considering.
I am just glad our team is not alone.
p.s. We are trying the XP method with storycards for each piece and use RCS to check in -out code. Seems to be working. -s0lar1s8 score 0
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.
I've seen programmers in India have problems from bad American specs by the American company that hired them.
Based on my experiences of the past 20 years working in Unix OS, Networking and Graphics development organizations. Good practices and team culture can overcome weaknesses in any given development process model.
IMO, no single model works well for all projects. The development model that best fits the project requirements and the team culture will usually produce the best results.
What I've found is that when Key Practices are performed on a daily basis, whatever model is in place can be sucessfully managed.
Key Practices:
Change Control: this includes; source, binary, requirements, decisions, action items, specifications, hardware, firmware, processes, practices, etc...
Communication: the ability to notify and acknowledge change
Assessment: the ability to review change and make corrective adjustments in the schedule and requirements
Planning: the best product bosses work their plans every nite, and publish every morning
On Demand Crank Turn: the ability to turn the crank at least once a day. This includes: build, package, assemble, test, publish, assess, plan, prioritize
GigantanKramePithicus
If a good project manager sits down with the customer and describes back all of the functionality that the customer wants, then there will not be an issue. However, project management is usually lacking with follow-up and follow-through for more complex projects, and programmers end up asking the Project Manager what the customer wants, and the Project Manager answers as if they know, but they are guessing.
I've done code enough to see that happen again and again. However, if the programmer talks directly to the customer, nothing will ever get done, because the programmer will ask far to many questions - confusing the customer in the process.
In conclusion, Maybe it's really a lack of compitent Project Management. Again, room for personal idiocy.
Kinetic stupidity has a new brand leader: Allen Zadr.
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.
The only reason India programming entities have been able to achieve high CMM levels is... cost
If a commerical company in say Silicon Valley attempted to achieve CMM L4 or L5 they'd never ship a product
I have first hand experience at two companies that made these attempts... and have talked with other development managers which have walked away from CMM
The main problem with CMM is it is only focused on the process. But the reality of the market is that we develop and publish software very quickly. CMM needs to be tailored to accomplish both the business and SDLC needs
GigantanKramePithicus
So how well does Aegis work with OOPs languages (like Smalltalk) were code and change are tightly bonded?
It sounds to me that a form of Groupware for the development process would smooth some of this out.
Maybe a blending of a WiKi with Bitkeeper (or Aegis) plus Planner would work.
It doesn't eliminate bloatocracy so much as make it more transparent.
As an employee of a US division in a German corporation, I think I can shed some light on why US developers skimp on specifications:
We're too busy coding.
The truth is that commercial development schedules are unrealistic. If it would take two years to do a project correctly, only eighteen months will be allocated. This leaves the developer in a quandary over which part of the process to skimp on. US developers choose to skimp on specifications, while German developers choose to skimp on implementation.
That's my experience anyway. I've seen specs from Germany that are so padded I think the author must have stock in a paper mill. And I've seen the incomplete software that arose from it. In one instance a product was shipped that was completely unusable, whose only sales the first year were to the sales department as demos, but which won a corporate award for adherence to the process.
It's simply a different way of working. To the US developer, if you can't do it right, at least make it work. To the German developer, if you can't do it right, at least go through each step of the waterfall model thoroughly and methodically until your time is up.
Just about every corporation views the process as more important than the product. But their individualistic and rebellious nature means that US developers will work on the product anyway. But German developers will just do what they're paid to do.
Don't blame me, I didn't vote for either of them!
If you are building a compiler, you would want a spec. If you are putting up the new corporate HR site... you would be better off to just prototype closely with the customer and write the spec when the project is complete (meaning that it meets the actual need). Why write the spec at all? Years down the road when all involved have forgotten the minutia and a replacement is needed, say to move the product to a new platform, the spec will come in very handy. Many projects just don't need a spec at all as in 3 years they will be completely obsolete as business processes are changed in a seemingly whimiscal way.
Software 'engineering' is not manufacturing. When designing a new car much of the planning involved is to make sure that the plant provides the tools necessary to do the job. Very few software projects require that you build new tools to get the job done.
Of course there are exceptions. I certainly hope NASA is writing specs first. Specs, however, almost always lead to feature creep in the software world.
In the vast majority of cases programming is more akin to a craft than a science and most programmers are much better artisans than engineers anyway.
Their analysis shows that projects that do not use detailed specs but do use prototyping can be as productive and produce the same quality of work. (page 14).
Well put. I noticed in practice both you and the client experience a development process. You develop software, while the customer simultaneously develops an understanding of their own business or problem. Looking at it this way, it is clear immediately why a waterfall development approach won't work.
But still at the development shop where I work, the gospel is to create a detailed requirements document (including quote) beforehand. The customer must sign off, and development starts. Every project I have seen performed so far has ended in sour feelings on both sides, due to the customer wanting to change requirements midstream. And everytime I'll hear other developers complain about customers who do not know what they want. It baffles me that no one (especially management) tries to find a development form that can handle changing requirements in a smooth way.
Extreme Programming promises to take care of this problem, but I'm not quite sure how you'd make an initial quote. The feeling at work is that customers will only accept a quote which promises to deliver a certain set of specifications for a certain price. Apparently, customers themselves do not realise beforehand that their requirements will change over time. Therefor, they will prefer a quote which promises them to deliver what they think they want, rather than a quote which promises them a best effort in a rather open-ended time frame.
Anyone have any experience with quoting XP projects?
Imagine NASA writing software without specs!!! The truth is that dynamic commercial environments rarely do need specs...all they need is a general outline of the concept being agreed upon all parts. Then, changes can be easily incorporated and new stuff can go in and thrown out at will.
But there is a large class of software that can't be done without specs, and it is the software that drives your life: from satellites to power lines and nuclear reactor control, train management, airplane traffic control, defense applications, all these things must have specs, otherwise a tiny error can result in losts of lives lost and million of bucks thrown out of the window.
"but I ask, what novel piece of software was invented in a developing country?"
First of all, how many languages do you speak and in how many developing countries have you ever been?
Ok, just two worldwide known: Prevayler and the Health System Java Card (I don't know the official english name of this project, but they were awarded at the last JavaOne).
Sorry to tell you, but USA is not the center of universe....
Yeah, but then a techie can say, you need a grid of flexible cells which can hold a value or a formula, and the customer says 1-I don't want a operating which you'll end up developing (i.e. framework/API) , 2-No I need a hierarchy (i.e. tree), or 3-IT's too slow.
Hey, a developer will never have enough time to understand the business rules, period, unless you quit being a developer and do the customers' job. So...the specs have to START at the customer. Developers that think they *know* what the customers' want is thinking back in the dotcom days (uh, can I say dotcrash!). Developers should have the ultimate say in design, but they should not be the driving force.
absolutely not. The requirements are what the customer wants. The analysts then get together with them and thrash out what can be done, what you can do, what they should accept given time/performance/risk constraints etc.
But in the real world where contracts are not quite as well defined as you'd obviously like (unless you work for a governemnt/military/telecoms/etc, etc sector that does have firm design specs) you'll find that the spec often doesn't do quite what the customer wanted.
This is the cause of many problems in waterfall design methodolgy for example.
Now, as a programmer you may not see the requirements at all - and the specs then are your 'reqs', but for the company as a whole - na, the customer will only be happy if it does what they originally wanted, regardless of what legal contracts have been drawn up (they only contain the blame after all, not contribute to good software engineering).
My current company, for instance, has a good working relationship with our main customer - we don;t do specs at all (its great, I get to work on stuff without doing masses of documentation). They're happy with what they get, and when there is a problem it gets sorted out and everyone is happy. Unlike many contract-based relationships where everyone is unhappy with the compromises that are made, and the project managers just bitch at each other.
If you do something like RUP, then requirements ARE your requirements, your test plans are based on your requirements. If you do something like XP, requirements ARE what you base your test harnesses on, and they are your specs and requirements, and practically your design too.
was written up almost a year ago.
The big painted cake in the sky for software development has been user-driven requirements and giving the user what he asks for. After all, the user wont be happy with anything else right? Problem is 113% of the software users out there have no idea what they want, or can't get specific about it. The only REAL development that I've done this year has been driven from the inside, based on requirements and timelines put in place by developers themselves. Most of the projects that came from the outside were requests to put hacks on top of other hacks that already existed in an organization. These were lacking clear specifications and were full of assumptions and caveats. Often the simplest solution had to be avoided due to a desire on someone's part to utilize a new, unfinished, poorly documented standard because it promised to be the next revolutionary trend in the market, according to it's shadowy working group. The assumptions and caveats usually ended up killing the projects, that and the limited value of the end result. Most of the time the non-technical manager type folks that initiated the project just got some other more exciting itch to waste money on, and went off to scratch it.
TallGreen CMS hosting
Hence (I hope) the need for systems analysts and such - to bridge the gap between the customer and the developer / programmer. Granted, a good programmer can make the translation themselves, but they really shouldn't have to - they have heavier lifting to do.
That said, I am a Business Systems Analyst for hire, so if you need one, let me know! [/jk]
Battling Beasts
I *see* and deal with requirements all the time. My company does embedded systems for the military. Requirement specifications aren't just what the "customer wants." They are a contract agreement of what the customer is paying for. Believe me, if we didn't meet what is in the SRS (Sofware Requirements Specification) we would lose funding for current contracts, and all future ones. Your company may not do specs, but as an SEI level 5 org. (and CMM level 4, trying for 5) we are required to.
Anonymous Cowards suck.
In other news today, the White House begins a study on world diplomacy.
When I was writing business systems in COBOL in the 1970's we had all the same problems and all the same arguments.
The one thing that seemed to work well was the polymath style of person who had coded for at least a few years in that industry and then been promoted to the level of "Business Analyst". Having line-of-business area specialists who also knew about programming and the personalities in the user base write the user-level specs permitted reasonably successful systems in a reasonable amount of time. These people are both "Suits" and "Techies", at least to a certain extent.
Nowadays there is more computer sophistication among the user base, but the problem is not eliminated.
One thing you need to reduce or eliminate is the raising of business questions in the middle of coding, where the progammer has to stop software development to go out and research more requirements. Half the time they discover they need to rebuild what they've already coded, as it isn't appropriate.
Area Specialists
In the 1970's I worked on an accounting software project where the very successful but bull-headed boss had canned all the accountants! Needless to say it didn't matter that the code worked brilliantly, from a technical point of view. I did learn how to code a table driven Binary Search in COBOL, however, it added no value to my user base.
When the corporate level evaluated the software and, of course, found it to be a complete waste of time, I was personally accused of stealing company resources by writing useless software. That's one meeting I will never forget.
I digress, but that was when I learned that there are some managers and "Business leaders" whose only management tool is to apply pressure to their staff, as they don't understand anything else. At all.
Years later I worked on an embedded data acquisition system where the hardware guys had to reverse engineer the data sources so we could extract the data. Massive chaos reigned until we found a retired engineer who actually understood the massively complex old hardware systems with which we were trying to interface.
Don't Build What You're Told
It doesn't take a software developer long to realize that the software customer base is rarely happy when you build exactly what they specify. Some of the more intelligent customers (aka "Users") have learned to deal with this by refusing to agree to a spec.
Successful business software developers learn early that you build what they need rather than what they say. Of course, then you have to sell it to them.
It is this disconnect between user requests and user happiness that gave rise to the collaborative techniques that involve the User in specifying "Use cases" and all that, so that they are emotionally and politically committed to a particular solution before coding. Of course, this method allows the user community to learn about IT/DP from experience.
I18N == Intergalacticization
Nail. On. The. Head.
Yow! I'm supposed to have a plan?
That is a really great cartoon! Thanks for sharing - I'd love to know where it originated as well...
Face it, folks, we're never going to get "good requirements." Non-technicals just don't think that way. Really. We're always going to do iterative development. We always have and always will. The only questions are (1) do we do it intentionally and well and (2) do we admit it or claim to be "CMM5" or "well-managed" or in some other mythical state. If you think their brains work like ours, consider this: if a colleague ever told you s/he didn't know how long it would take to complete something, would you ever ask how long it would take to do 20% of it? That question makes sense to them. If a colleague told you something you wanted was not quick and easy, would you say something like "could you just to a simple one then?"
.)
The advance will come when we learn to accommodate them and communicate with them by learning how they think and when we break out this infinite loop of waiting for them to understand how we think, what we need, and what we want. I like agile, but it dies on the assumption that anyone in business gives a damn about how developers want to do things.
Real story: Enthusiastic, but naive newbie in the dev team goes to PHB and asks to do XP, including setting up in a room, not in widely separated cubes. The X-word scared the hell out of her and she enlightened him about sub-humans lower than directors not meriting offices. Zen master tech lead waits three days, informs PHB the team will be "programming in pairs". "OK." After 4:30 pm PHB departure, lead gets key to unused office and sets team up in there. Next day, when PHB asks, lead informs her they had to relocate for temporary team testing in order to not be too loud and make other cube-dwellers less productive. "OK". (All this still within IT . .
We'll never advance while we're blinded by our own righteousness. Never mind wondering why they don't pay us more.
I believe that offshore programming is the customer reaction to being mislead by poor programming stateside.
In short - the customer says the computer should save time by making information easy to enter and get to. So they put out for the lowest bid - they get crap, and then they want it changed (it breaks) and the project is up in smoke.
That they can get in india. They can start fail - start fail, and finally get something working for the price of a single faiure in the US.
To keep customers here - we need scalable solutions.
AIK
Where I work my boss is an alcoholic with a rage problem. Being a small company, he is the only person to report to other than respect-based program-to-programer approval seeking.
Design meetings generally follow this format:
The boss man interupts an important programer/programmer technical discussion that was drawing to a close (approx 2 minutes remaining). He asks some questions about technology he has no hope in hell of ever understanding. He claims he understands it and says "so its kind of like..." and then proceeds to say something that indicates he has no understanding at all or that he wasn't even listening. We say "no" he gets mad b/c he is always right and decrees we do things his way because we are "idealist" scientists and he is a "practical man" and somehow therefore is right about the fastest way to write code. Argument insues for two hours over a medial issue. Boss man consumes three irish coffees and breaks two pencils. Boss man queries "So did I make it simpler?", we say "no not really". He breaks another pencil and leaves to starbucks to get another coffee to spike.
Needless to say there are a lot of broken pencils and spilled coffee cups in our alcohol reeking office.
http://brandonbloom.name
I just sent this out in an email to my company. I said "this is going in our training manual." Too too accurate!
Maybe we DID take the blue pill. You wouldn't remember anyway.
And that's why the US military has shitty software that,
while it does exactly what was specified, doesn't do anything actually useful...
First off, how the hell would you know, Mr. Anonymous Coward? Secondly, software that does what it is required to do doesn't do anything useful? You are just trying to be an asshole. Now put down the Star wars figures, and leave your mom's basement.
Anonymous Cowards suck.
Requirements are what the customer wants.
Design is how the analyst thinks it should be done.
A specification is the medium used to communicate these. It might be oral, written, multimedia, knock yourself out.
You can have a written requirements specification (which is what the article's talking about), a design specification on a whiteboard, etc etc
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..."
http://www.sei.cmu.edu/ The Software Engineering Institute at Carnigie Mellon University teamed up with the US Air Force in the early 90's to study just what is wrong and what is right with software development and processes. The results may suprize you, if you take the time to review the site. I was suprized that no one has mentioned Capability Maturity Model CMM yet in this thread. Morons. Viva CMM!
I've seen a shorter, but in the main issues same, version of this already 25 years ago as badly copied drawings.
Knapp vorbei ist auch daneben.
Wow! It's a wonder that architects of buildings and site supervisors/foremen haven't applied your keen insight in the performance of their jobs. Their customers are ignorant of the technology and techniques, so what possible contribution could a customer make towards the task of constructing a building?
So, have you considered that it's your (or someone else with more experience's) job to translate the customer's non-technical requirements into some facsimile of a useful specification? Or do you just code in a vacuum, absent any planning and devoid of any input or feedback, in the hope that the end result has some relevance to what the customer requested?
If so, please shut down your computer and set away from the keyboard immediately, because you are part of the problem.
---anactofgod---
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."