Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software


What are some good ways to get better at this? 

I often fight with the lead developer on this... no fistcuffs thrown but just big conflicts of ideas.  I find myself much better at "sketching" an idea while working on it rather than writing umpteen documents describing "how" I'm going to solve a problem.

How do you deal with paper trail, making sure you document how long something will take but recognize an inability to write a perfect plan before you really know what you're working with?

David Seruyange
Thursday, May 6, 2004

This book talks a lot about that:

Boiled down, the advice is to make estimates, keep careful track of how long things really take, evaluate the accuracy of your estimates, and learn from this so your future estimates get better.  It's worth reading the book to get the details, as it's a good book in other respects too.

Thursday, May 6, 2004

My answer would be that it depends on the size of your organization.

For example, take a government agency, or a large IT shop like Bank of America. They have architects and engineers and business analysts, and generally would go through all of the steps in the SDLC. That's perfect for them because they have the manpower and personnel to implement it.

In a smaller IT shop, it can be best for one developer to work on a project. *However* every developer needs a development manager. If your IT shop consists of one developer, you need a development manager. Someone to make sure things are happening on schedule, and to take a higher-level view of what is going on.

But going to this question:

>How do you deal with paper trail, making sure you
>document how long something will take but recognize an
>inability to write a perfect plan before you really know
>what you're working with?

The trick is to break it down into chunks you *have* worked with before. For example, if you have an application that requires user authentication, you may be able to say that it will take you 160 hours to build that, because you have built one in that exact environment before. And if you haven't, you start breaking it down to login and verification. You know you need a login screen, and a query to your security source to validate the information, so estimate that. If you can't, break it down to building a screen, building a query, etc.

By far, for us, the most important thing is to have all of the requirements down. If you feel confident that the requirements you have aren't going to change (that much - they all change somewhat) then the design process is more up to you.

The book recommended, Guerilla Tactics for an Imperfect World, is excellent. I would also recommend a book like Code Complete by Steve McConnell.

Best of luck to you, and if you can keep it going from fisticuffs then you are ahead of some dev shops I've seen. :)

Thursday, May 6, 2004

You should post things on JOS forum if you meant it to be read..

Here is like the desert, man..


I always make my pioint throug explaining how you'd never get a Word document describing how your house is going to be built instead of an enineering and architectural drawing.

.NET Developer
Friday, May 7, 2004

The analogy I like the best is when you have to convince someone that throwing more bodies at a problem won't help:

Nine women can't have a baby in one month.

Steve Jones (UK)
Saturday, May 8, 2004

*  Recent Topics

*  Fog Creek Home