Fog Creek Software
Discussion Board

Starting a new Project

At work, we're starting a major new project, essentially a rewrite of our current product to make it more useable and rethink the design.  I've figured that we have to survey our users for enhancement and improvement ideas, write up a storyboard at the user level and put together a rough model, and also do a storyboard at the technical level. Where do specs with the user model and the actual implementation come into this?

Also, what have other people's experience been with starting fairly large projects in a small company, in which the environment has a lot of side projects and the (two) developers wear many hats (programming, tech support, etc, etc.). In fact, the other developer mainly has to focus on running the business, so how have other people found ways to stick to something like this?


Wednesday, April 9, 2003

3 years ago I started a solo project that, by rights, I had no business attempting.  Lack of experience, training, and financial resources;  Alas, as the saying goes 'I didn't know it couldn't be done so...'

Fear, desperation and hunger are the best motivating factors that I've come across.  Derision and having EVERYONE tell you that you should be wearing a helmet and using a spork is also helpful...

Now with the advice... DON"T DO IT!


I get very nervous with the word re-write.  Joels Netscape article, which is excellent, is worth reading 6 times.

I went down the re-write path more than once and found that I had, essentially, exchanged one issue for another after months of effort.  Yes the bugs were much more elegant but bugs none the less.

Refactor, Refactor, Refactor

Did I mention refactor?

Everything else should take care of itself with the proper planning and adhering to a proven method.  Above, all is the unadulterated belief that you will finish.  The minute you even acknowledge that there is another option is the moment when you should start sending resume's.

Too much coffee!  Good Luck!

Wednesday, April 9, 2003

What makes a rewrite not that bad in this case is that the current version would be updated until the new one is ready. It would always be avaliable to revert to. When it was first launched, it was divided up into logical categories, with a few animations in each. Now as the number of animations has increased, it's becoming less easy to use and needs better structure.

Wednesday, April 9, 2003

Ask your users for comments *first*.  Before you do *anything* else.  Don't even think of a new design or interface.  Just ask current users how they think the system could be improved.

Base your changes on user feedback.

I say this because I've found it too easy to come up with the logical, "best" solution without asking the users.  I've always been surprised by what the users wanted, and their suggestions have always sent me in exciting new directions.

Brent P. Newhall
Wednesday, April 9, 2003

It might make the project easier if you didn't try to "make it more useable" and "rethink the design" at the same time.

Why don't you split your planned work into two parts. First, do the architectural rethink/redesign but aim to keep the interface and functionality exactly the same. This will make the work specification much easier and possibly less prone to introduce new bugs.

Then tackle the major overhaul of the usability/functionality of the product using the fancy new base.

Bill Tomlinson
Wednesday, April 9, 2003

I'm going to have to agree with an earlier poster....


How many of us have been on a 'rewrite' project that failed completely, or was delivered so late that people joked about it, or delivered on time with less features that the original, or....

happy to be working
Wednesday, April 9, 2003

Manage expectations.

For End Users - Make it clear you wish to hear EVERYTHING, and you will look for the items that are most requested or able to be integrated with relative ease.  I see too many of these sessions setup where the end user is all excited about being involved only to see nothing at the end.

For developers - Tell them up front about the time line and involve the people who will have to code.  Some will think it a waste of time, which is probably another issue all together, but hearing it first hand is 1000% over reading a specification.  In addition, developers need to be told the words "cannot be done" are forbidden.  Later they will be asked to tell you how it could be, not why it cannot.

For leaders - any timeline costs money.  Read and Understand Rapid Application Development.  It will save everyone heartburn later.  Also have any technical leader read it too.

Mike Gamerland
Wednesday, April 9, 2003

Read the Camel. Do the opposite.


Wednesday, April 9, 2003

I totally agree with what others have written.


Seriously. It's like using GOTOs.

Talk to the users. Draw up a list of the changes they want. Implement each change in turn. Don't start working on one change until the last one has been completed. Do all the easy changes first so everyone can see that progress is being made. Earn their trust, then tackle the big stuff.

I've personally witnessed two companies go out of business attempting to rewrite software. Please don't make the same mistakes I did. No matter how bad it looks, existing code is always far superior to hypothetical code.

Angus Glashier
Thursday, April 10, 2003

I also started a rewrite project three years ago. Yes, it *was* a death march project, but, yes, I succeeded in the end. Although I agree that you should never rewrite if you can refactor, I'd say that, if you came to the conclusion that you *have* to rewrite and you *can* do it, this is a "Big Hairy Audacious Goal" in the best sense. Just flipped through my notes:

+ Make a Painless Software Schedule. Also my experience is that schedules do not hold for longer than about three months, it's still absolutely necessary for you to estimate the effort.

Then, ask some "What if ...?" questions. For example, if you estimate x hours for your project, ask "What if we only had half of the time?". Think about which features can be done in x/2 hours - these are the features you *can* do in x hours.

+ Score high on Joel's 12 Points Test. First, get to your customer. Then, setup your CVS server, bug tracker etc. [you already do use it, don't you?]

+ Get an absolute code guru for your team. You know, somebody who virtually knows *everything* you always wanted to know (of course, you also have to dare to ask).
By the end of the project you wil be at guru level yourself, because in a small company you have to take care of everything ...

+ Split up the project into several independent parts. Then, suddenly you'll find out that part 1 was already done by another division of your company, part 2 happily waits on sourceforge for you to download it, and only parts 3 and 4 are left to be done by yourself.

+ Do not split up the team. "You should not changes horses in the middle of a river." Better a small team which will stick together until the end of the project, than a large team where every now and then somebody is leaving and has to be replaced.

- Roland
Thursday, April 10, 2003


rewriting from scratch fails in most cases. Working for a small company does not make things better unless the company has a deep enough pocket available.

IMO, it is essential to break your project down into smaller subprojects and deal with those sequentially. The advantages are:
- smaller projects are easier to fund and manage.
- smaller complexities are easier to deal with.
- you end up with a modular product which can be customized, packaged, sold and marketed easier.
- company can start making money earlier by getting the first modules early on the market.

Where do specification fit in? Hmmmm ... specifications come around when we try to answer the following questions:
1) What is the problem we are trying to fix?
2) What are the capabilities we need to address the above problem?
3) How should these capabilites be employed to effectively address the problem?

Requirements answer only the second question. But you need all answers before you can write your first line of code. Partial answers are ok to start with because as the project goes on they evolve towards their final v1.0.0 shape.

Without these answers though, you wouldn't know what you're doing ...


Thursday, April 10, 2003

Sometimes you just have to start again.

I have been architecting a rebuild of a simulation. The old version was built to run on a single machine. The new version was built to be distributed. Therefore the old version assumed that all necessary data was accessible easily and quickly. The new version required a completely different architecture, because many of the original assumptions were no longer valid.

Several points:
1. Scoring high on the Joel tests is an absolute must.

2. Reflective practice really helps as well. You probably have people in your organisation who were involved in building the original. They are an absolute goldmine of institutional information. Use them. They know why things were done the way they were. Some of them may be "we were out of time"  or "the manager wanted it so", but they will also be full of useful nuggets like "There is a particular case where X does Y, and if Z isn't configured in the right way, the whole thing falls over". Hopefully they should be able to tell you about how things were received when the first version shipped, what worked and what didn't, and where the problem areas were.  Learn from your mistakes.

3. You will still probably not have worked out all the issues. On the project I am working on we spent a long time working out the basic distributed architecture, and talking with the systems engineers who understood the detail of what we simulating (telecoms infrastructure) , and tried to work out exactly what they were trying to do before we started writing. The result was that we deliuvered an architecture that did what was required of it on time. The problem then was that the reimplementation of the telecoms infrastructure then started going slipping horribly, because they had not understood the different headspace required to write a distributed rather than a monolithic simulation (Although to be fair, these people are very hot systems engineers,  and only do C++ in their spare time!). On the other hand we have uncovered a lot of issues with how the (simulated) kit should work by moving to a distributed simulation - so it hasn't all been bad.

4. Joel is also very right about ensuring continuity of product. We have ensured we have a working monolithic (old) simulator pumping out rersults while the new simulation architecture is being built. This means that we can keep pumping out the goods to our customers, and bring in extra data from the new simulator as and when the new version arrives. Even if you are working on a com,plete redisgn of your product, you may want to refactor your old product to make it more compatible with the new one when it comes out. This will mean that it will be less of a jump when it happens. Can you update file formats? the look and feel? the capabilities? Make sure your users feel that there is a continuity of a familiar product, because otherwise you have a great opportunity to piss them off!

Hope this all helps,

Thursday, April 10, 2003


What are you planning to rewrite exactly?

You have a 3D animation product there.  Are you planning to rewrite the animation engine?  Are you rewriting the editor?  The library?

Ged Byrne
Thursday, April 10, 2003

We're redoing the interface and integrating it with another one of our products and generally making it more intuitive to use. Windows Media Player drives the video right now, but we're going to design so that we could drop in something else easily.

My current plan so far goes something like this:

    User Survey
    Rough Storyboard
    Rough Model
    Technical Storyboard
    User Focus Group
      seperate times
      at our offices
      with film
      no one but the user present (so that people who know more about the product CANNOT direct the user as to what to push)

Thursday, April 10, 2003

Don't fix it, if it ain't broke. Preserve the time-tested code.

Just my .2c

Friday, April 11, 2003

*  Recent Topics

*  Fog Creek Home