Hey happy coders,
I’m currently developing a “2-weeks-max” application for an Israeli bank (If you see “Israeli bank” instead of the name of the bank, you don’t have sufficient privileges ;-)). The characterization was written and approved on the fly, without a deep understanding of the client’s domain, i.e what are the other applications that the users use in his every day work ? are they look the same ? does he “MUST” have some features that his already used to in his other applications ?
Now I’m facing the harsh results.
I’ll give you an example of “little-MUST-feature-that-can-come-back-and-bite-you”. The user requested a screen which will have to following fields in it (and some others, but they’re irrelevant now):
- Requester drop down list: show all the users from a specific group in the AD (active directory).
- A->B->C linked drop down list: 3 DDL (drop down list) which are connected meaning that when you select a different value in A DDL all the values in B&C DDLs must show all the children of A (changing B will change C values of course).
This looks like a trivial requests right? Well, you’re right, if you look at this skeleton request it may appear trivial, but the key is to understand how to user expect to choose a value from those DDLs. In my case, the user likes to work with auto-complete drop down lists. Combining his auto-complete mechanism in this screen was NOT a trivial task at all. The client gave me his code, so it seems that I just have to integrate it in my code and Voila; BUT The code was written for ASP, so I had to wrap it in a custom web control, handle the viewstate of the control, and worst – his code didn’t worked so well (client-side behavior) so I was required to adjust and fix it as well(black box component in my a$$).
The 2 weeks application is now estimated in 3 weeks, 50% more than the first estimation !
I’m expecting a good night 24:00-06:00 sleep at the office for the next 2 weeks, wish me luck !
Some lessons I’ve learned:
- Don’t give a fast reply for hours estimation just to move along and get the development process running, it WILL hurt you later on.
- Always try to understand the solution domain as well as the client’s domain. Ask him to show you other applications that he uses for his every day work, ask him if he wants the same GUI in his new application that you’re going to develop for him. If he does, think about the amount of time you’ll be needed in order to do that, do you need to use a specific “template” so the new application will look the same as his old ones (how are you going to integrate it with ease?), do you need to allow him some special features that his already used to (auto-complete drop down list)? do you need to support key combination (Ctrl+S will save his document) ? In a “clean”(without technical considerations) characterization it probably will not be shown, but you must consider it in the technical characterization(if you have one) and in your total hours estimation ! Don’t forget that the user thinks that adding a new feature to the application is an easy task because he already saw those features in other applications he uses every day (“can’t you simply copy it from here???”) – you must remind him that it’s not a trivial task, and allow him to choose if he wants to spend time on these features.
- “Milk” the client for information, write all the possible scenarios that the client expect the system to handle. What screen X will show when I login as Administrator, what it will show when I login as Technician, as Supervisor ? Don’t start programming unless you have the answers for those client “trivial” scenarios, refactoring will be a bitch !
- update: just to clarify, I didn’t write the characterization and neither was my PM (project manager), it was written by another co-worker a long time ago. This is a huge mistake IMHO, you must ask the implementors, if you’re not one of them, for their opinion on the development process before you can give your hours estimation.
Any tips you can share with me ?
yoyoyo, my man.
hi, i like your blog it is great, and your tips are very useful.
i know u – so i must add that two weeks estimation equals to four weeks for any other programmer.
one more tip, you should pay attention to those user/web controls
to write them general as much as you can (never say i’m in hurry i’ll fix this later).
many times "medium" programmers (java ones :) says: "if i’ll write it dedicated to the relevant page it will take me less" but always rememeber that agile development is for the long term.
so you might work for 4 weeks but next time it will take you couple of hours to use those componentes.
i have a great site for writing components: http://www.nikhilk.net/ you should all read his book on components.
love u,
d – e – f – e – n – s -e
Hey Shani,
thanks for your support, I’m glad that you like to read my nonsense :).
I totaly agree with you about the development of multi-use controls, but sometimes you must remember that for every day you past your deadline, you’ll have to pay a fine (as long as you’re not in the army, of course ;-)).
So IMHO, you have to estimate the amount of time you’ll need to invest on the specific control and think if you have the time to invest in it now; 1-2 days for of work on control from 2 weeks is not acceptable, as I’ve said, time IS money. It’s a hard trade-off, but I think that this generalization can and should be done when you have "space" between projects or you have a longer development time (in a 2+ months project, 2 days is acceptable).
* If I’d to do the hours estimation, I surly not estimate this project by 2 weeks, but it wasn’t in my hands.
p.s – thanks for the link, I’m reading this blog (with my SharpReader), I’ll add it to my Blogroll.
Actually, I think that in the army they send you to prison if you’re late on your deadline :-)
Heh, you wish. There’ve been delays on important projects that span months and years with absolutely no reprecussions for anyone…