Fog Creek Software
Discussion Board

Writing Specs in the middle of the life cycle

Functional Specs are very important part of the software life cycle, however, many people don't do it, including the company I work for.  Because they never have any specs, I dont believe they should never have one.

My question is :
Would it make sense to begin producing the specs in the middle of the life cycle?

How can it work ? while new functionalities and bug fixes are being done each week.  Suspend everything for awhile?

Monday, March 11, 2002

If you are planning to do more releases, Yes!!!!!!

Worked with two products where this was not done (despite peoples suggestions)
observations are:

Testing is much easier if you know how a product should work.

Maintenance is much easier if all the developers know how some of the more intricate API work.

It does not have to be a full functional spec document all at once. consider starting with the more intricate API, The API that will be changed in the next release, and the more intricate parts of the UI

Daniel Shchyokin
Monday, March 11, 2002

Yes. You definitely have to write specs. But for existing functionality I would not wite them as a document. I would write them as an automated functional test set.

If you think this is impossible - you are wrong. We following this practice and it saves a lot of time.

Roman Eremin
Tuesday, March 12, 2002

I'd start writing specs for any new functionality.  Then write test cases and such for the existing app.

Been there, done that.  It's not pretty, but it works and is better than not doing specs at all.


Bob Crosley
Tuesday, March 12, 2002

"Would it make sense to begin producing the specs in the middle of the life cycle?"

Yes do so!!!  You can have the current new functionality documented even after it has been just built.  Then at least the testing group will know how a new feature is implemented instead of trying to guess what it does.

"How can it work ? while new functionalities and bug fixes are being done each week. Suspend everything for a while?"

Well, you might need to revise the schedule to add time to create the functional spec. Any, new non-built functionality needs to be documented such that a user or a tester can determine what the impact of the change is. Everyone can critique the functionality, thus prividing a better final product.

I would not do functional specs on already established /tested functionality, unless it is difficult to know how it should work.  This can be captured from the already exixting manual (ye hope)...

Paul B.
Tuesday, March 12, 2002

Hi Ray,

I've been through this type of project before. All I can say is:

1. It's never too late to write specs
2. The specs will actually help you control the feature creep, and get a better handle-hold on the project. Your next step would be to institute a "change control board" :-P
3. Don't forget - if this is a user product - to get lots of screen shots!
4. Have fun (read joel's stuff on specs)

When you are working with specs, what you will have to do is incrementally introduce the specs to the project. So you are going to have to figure out a way to partition the project into visibly manageable sections. (btw, I know no specifics about your project, so I can be totally off here - especially if you're working on an embedded system or some esoteric back-end library).

When you're done with each piece of the spec, it's time for some subversive software management. This is where you can get some software process into place. You should now sneak in the "change request" system and break up the difference between "feature creep" and "bug fixing", since organizations often use one interchangeably with the other.

Supposing that you can get this far, your project would likely be in much better shape.


James Wann
Wednesday, March 13, 2002

While writing specs in the middle of a project is probably better than having none at all, I wouldn't think of them so much as "specifications", rather they are "justifications." That's not all bad: the document can still act as a "contract": you can get people to sign off on your written justifications and have something to refer back to when people start changing their minds or forget old decisions.

When that happens, if it's all internal work, then you might just end up with pissed-off co-workers. If it's for clients, you'll end up eating time and money, since it's hard to convince clients that *your* memory of some decision four weeks ago is better than *their* memory of it.

If new functions and fixes are happening constantly, you're probably running into communication problems--when did we add xyz? Two weeks ago? Will it work with my new function abc?

It's not a bad first step to real specs if you start writing careful and complete test script documents. Testing without a plan is as dangerous as building without one.

Friday, March 15, 2002

Forgot to suggest in my last post:

"How can it work while new functionalities and bug fixes are being done each week? Suspend everything for a while?"

If you're pulling programmers off coding work to write specs, you'll likely get hastily written and bad specs. The smartest thing you can do is to hire someone who's good at writing specs (and test scripts) and give them this task full-time. I promise you that the addition of a good spec writer will improve your schedule and budget planning, as well as your project quality.

Friday, March 15, 2002

*  Recent Topics

*  Fog Creek Home