How to Make a Software Project Work
(Success not guaranteed, but these tips should help...)
By Antony Hirst
January 4, 2003
I have some rules of thumb for business software (any language) that have helped me overcome the usual problems inherent in not only creating but delivering dynamic and changeable business software projects:
"Understand the business."
1) Understand the business
It is shocking how many developers don't actually know much about
the nature of the business(es) that will be using their software.
This often means spelling out the obvious using some kind of Business
Process diagramming and using that to clarify requirements.
2) Use Cases are useful, but...
Don't start with them unless you want endless pointless arguments.
I developed a system of Business Process modelling from which Use
Cases may be elucidated following a few simple rules of thumb. Your
business process drives you to the Use Cases - i.e. do not just
sit down and invent them from nowhere. The design starts with the
business process model.
3) Create a logical design!
This is a skill in itself, but what you are trying to understand
is the behaviour and responsibilities of the system. Logical designs
do not include any elements of system management, security, hardware
constraints, operating system considerations or performance.
4) Throw the low-level design away at the end.
This might be a bit controversial. Don't burden the project with having to document every single little
change. Design is best used to move from requirements to architecture
and to validate the implementation as developers extend the framework.
There is a crossover point where it becomes a burden. In my experience,
once the basic product is up and running at v1.0, the design just
gets a lower and lower priority until it is so out of date that
nobody looks at it. Why go through that pain? At the end of the
day, for the detailed business logic, you must have requirements
and a logical design. That tells you why you have what you have.
But for the detailed ("code-level") implementation, code
is the best documentation. Code comments should cover strange decisions
and CM should hold the maintenance history. (Note this is not saying
that code is the only design documentation!)
5) Design in Detail
During development, encourage developers to go to quite a
detailed level in the design. They will hate you for it... initially. Well
maybe at the end too! But, a few missed parameters can be a real headache.
Ensure that your proverbial Channel Tunnel meets in the middle.
"What features would you drop? Well drop them now."
6) Deliver the absolute minimum
That does not mean test as little
as possible or shortcut good design. That means only add features that are
needed. A quality product is one that fulfils its formal and practical
requirements with minimum complexity. This doesn't just cover the usual
cowboy attitude of adding features in development. What I mean is
prioritise all the requirements - everything. Imagine that you are at the
end of the project and it is looking like you are going to miss your
deadline for the third time, your job is on the line. What features would
you drop? Well drop them now. If there is time, do them later... there
probably won't be time by the way...
7) User friendliness is one thing, but what is meant by that?
Is it really that important that new users get to grips with the software in five
minutes, or is it more important that expert users can work efficiently? Do you
want the software to be admired for 2 weeks or in a year? Then think about
the expert users now.
8) Know the difference between a time estimate
and a complexity estimate
Your manager just wants to know when you will be done. That
attitude tends to permeate to Project Leads who then harangue their
developers on a daily basis. You should know how complex the problem is
before you can say how long. If your developers are missing their deadlines
then you know you got a problem with the way you estimate complexity. I
have found a particular statistical Function Point estimation method
particularly useful. You need a logical design for it to work though.
"Insist that items are tested properly."
9) Management: Insist that items are tested
Say to your developers: "I don't care if it is a week late, just test it." As a Project
Lead, absolutely the number one issue for wrapping up a project is
ensuring that, as a whole, everything works! This will not happen if you
enter the maintenance cycle too early because of bugs for the sake of
impressing the boss in the short-term.
10) Little bugs are your worst enemy
Basically reiterating the point above. Big problems are nearly always fixable without too much real
threat to a project. It is the little bugs, distributed throughout your
code that will probably be the cause of any lack of progress.
11) Have the right team and right number
Too many and you are hiring anti-resources that not only waste time but others' time too. Too few
and obviously things are going to be difficult from a schedule perspective.
Personally, I would rather have too few than too many. Some people I have
worked with have met this view with complete astonishment. But then they
probably only have a schedule estimate and not a complexity one.
12) When hiring, look for general experience over specific knowledge
You want to home in on their experience. Of course, specific knowledge
counts but the best developers don't usually come custom made for
your project. You should be looking more for good solid experience
in concepts and technologies and not get tunnel vision on versions
or products. General OO, RDBMS, C++/Java are the core set of skills.
Expert developers would have solid middleware experience. Obviously
you don't want to hire a team of four C++/Sybase developers when
you have a JSP/EJB/Oracle project, so common sense applies.
"Hire staff who are going to learn."
13) Hire staff who are going to learn
Complete experts can cause more problems than they solve and become very difficult to manage as
their challenge falls more into getting everyone to do things their way. I
know, I have done it on occasion myself (didn't notice until I took a step
back). We all know how motivated we are by projects that stretch our
capabilities. Possible exceptions to this are architects and DBA/UNIX
administrators. However, the need to consider this depends at what level
your project is. This may not mean posting adverts for WebSphere gurus, but
looking for breadth as well as depth. Attract applications from experienced
professionals with a range of relevant experiences. Also, don't hire
technical ability over business awareness. Many developers forget they have their jobs to help make money for their employers; key staff who
understand this will ultimately be a key part of the success of a project.
14) The Project Manager/Leader's job is to clear the way for the developers to develop
The developers should not be doing anything that does
not fit into the strategy of providing quality software. Your manager
should be clearing the way for you to project lead, and so on. However,
micro-management is common, especially when deadlines are tight. My advice
is don't do it. Also, if you find yourself being micro-managed you should
endeavour to shield your team from its effects to ensure that their efforts
15) Keep things simple, unambiguous and straightforward
Develop processes that do not require people on the team to
think too deeply about their day-to-day activities. You want one-click
build scripts. Clear practical processes for at least all common
activities. Also, consistent naming standards, design and file-systems are
"Teams work well when the decision making process is transparent."
16) Management: Always step into disputes and arbitrate.
In teams, arguments over design generally provide more problems than solutions. Develop a
process that forces ALL options to be considered and does not rely on the
forcefulness or articulation of a personality to get their point across.
Teams work well when the decision making process is transparent rather than
'great' ideas just appearing from nowhere after an after-hours discussion.
Use your process to gather information and then make a decision. If you are
not qualified to make the decision, delegate the responsibility openly.
17) When faced with solving a technical issue, ensure that one of your options is "Do Nothing"
Don't assume that just because there is an issue that there must be a compensating action. Quite often, making the
decision to live with a sub-optimal situation is the best choice.
18) Programmers: Don't be inflexible
Crazy code standards and religious
arguments over style get nobody anywhere. Fortunately with Java it is much
easier to control these issues as the standards are global and most
development involves integrating APIs.
About the author:
Tony Hirst is based in SE England, where he works as a software architect at Lockheed Martin; prior to that he has held developer, architect and project manager positions in organisations as diverse as small start-ups and multi-nationals.
Ten Golden Rules to prevent your project from failing
How to Write a Functional Spec
<< Back to Lifecycle