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.
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.
I’ve noticed that some programmers like to use performance (speed, smallness, some other measurable attribute) as the only element to be optimized.
It’s like buying a stereo system that has the largest dynamic range, even beyond what they can hear, just because it’s the largest. Or buying the fastest car, even beyond what they can legally drive, just because it’s the fastest.
I don’t have much of a fix for that, except to ask questions to get them to acknowledge that they’ve forgotten that someone else’s priorities may be different from theirs. I often don’t win.