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:

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.

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.

9) Management: Insist that items are tested properly
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.

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 are maximised.

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 essential.

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.

Related Articles:

Ten Golden Rules to prevent your project from failing

How to Write a Functional Spec

Talkback: Have Your Say

If you agree, disagree, or have some tips of your own to add... why not leave a message here?

Post a new message

interesting
dani gheorghedaniela@gmail.com
i want software projects
manjunatha gkmanjunatha@softzonesolutions.com

Post a new message

<< Back to Lifecycle