Thursday, 20 May 2004

Talk about the tradeoffs Tell them what you'd like. Really. If you'd like the application to perform well and you don't care as much about maintenance then say so.  If you know the application will be used for 30-40 years then tell them that you think maintainability is more important than everything else. I've found that amongst most groups of nerds there is a surprisingly large number of ways in which the various attributes of code (and architectures, UI's, etc) are traded-off against each other.  Some people will think that everything must be speed optimised. Others will spend forever ensuring that variable declarations are lined up in source files.  While others will obsess about W3C standards compliance and usability. If its your job to manage (or even better to lead) nerds then do everyone a favour and order the following attributes of their work from most important to least important for each project.  This will help ensure that everyone pulls in the same direction, will flush out conflicts by allowing you and the team to discuss problems with reference to the list, and may well help to save the project. The list of attributes I use (in no particular order) are: Correctness - does the application do its job; Maintainability - how easy is the application to modify; Performance - how fast does the application run (or how much memory will its use, disk space, CPU, network usage, etc); Speed of production - how quickly will the application be constructed; Re-usability - to what degree will the application be architected to allow later projects to reuse code. Approachability - (related to maintainability) how difficult is it for people who are proficient in the languages and tools used to build the application to be able to take on maintenance tasks. Process strictness - how important is following the process that has been nominated for the creating the project.  In other words, is anyone going to be sacked if they don't follow the identified processes. There are many more attributes that can be identified and, yes, I know that these attributes aren't orthoginal. And yes, everything needs to be balanced.   Remember: tradeoffs will be made between attributes.  This technique can help ensure that the tradeoffs you'd like are made. 3:39:46 PM   comment [] trackback []

How Long? If you find yourself standing mouth open, shocked, at the time/cost estimate given to you by your local nerd for something that you thought was simple then you are not alone.  This, of course, leaves you feeling powerless and frustrated since you thought it would only be a day or so to export the wub into the thingy.  After all, exporting the megaWub took only a few hours and was much bigger. What can be done about this?  If you are the estimate-asker then ask for a range of estimates: a quick one hour/day estimate to do something along "these lines" (be sure to explain what you are trying to achieve not just what you want done in technical terms); a one day/week estimate to achieve the same ends but in a more comprehensive form; and a one week/fortnight estimate to get a Rolls-Royce version. Its important to listen very carefully to the caveats that the nerd is going to place on each of the options - they are important.  The chances are that there is a quick option that is viable but it will have limitations and they might be bad enough that you will accept one of the longer estimates. If you are a nerd who has been asked for something:  Don't just give a single short answer.  Dig a little bit into the business problem that needs to be solved and be pro-active in offering multiple options (using the hour/day/week/fortnight time estimates as guides).  Be careful to ensure that the limitations of your options are well communicated and always follow-up with an e-mail to ensure that your information is properly understood and recorded.  Ask for more time to come up with the estimates if you aren't confident and ask your co-nerds for help. 9:48:59 AM   comment [] trackback []