|
Abstract
This article describes some practical tips for successfully leading a team of
software developers. It defines what success means and then describes some very
common sense tips for achieving that success.
What deems a project to be successful?
The primary goal of any software project is to meet the user requirements and
make sure the users are delighted. If something has been built that nobody
wants, it makes no difference what happens to staff turnovers, budgets or
training. If requirements are not met, the project is a failure. The next goal
after requirements is probably to complete the project within the required
budget. After that, there might be others requiring staff to be trained, and so
on.
Here are a number of tips for team leaders to help them achieve success in
their own projects.
Meet the correct requirements.
Getting the right requirements from the client warrants an entire article
itself and is out of the scope of this article. The key once you have a set of
requirements is to make sure that you only build those, nothing more and
nothing less. Very often you find developers who like to ‘guess what the users
want’ and ‘build things that are ‘very cool’. I’m sure you know the type. You
need to build a culture where creativity and suggestions are actively
encouraged, but ensure that those suggestions are relayed to the requirements
manager, and not immediately built by the developers. To drill this into
developers I often ask them how they would feel if they went back to a garage
to pick up their car after a basic service, to find that the garage had decided
to upgrade the engine to a new one, and that it would cost 5 times as much and
not be ready for another week.
Tip 1: Stick to the defined requirements. Don’t guess them yourself. Don’t spend
time and someone elses’ money building something that isn’t asked for, and very
probably isn’t required.
Manage Risk Early Focus entirely on the risks of the project and
mitigate them. This is the role of the team leader. Building a piece of
software is like trying to rob a bank. You don’t want to get caught by the
cops. The cops in a software project are all the risks that will stop you
achieving your goal. These risks will range across the board from requirements
risk, to environment risks, to technical risk. Example1: You finish the entire
code base on time, to find out that you needed to raise a change request two
weeks ago to get the software released into the live environment. Example2: If
you cannot integrate with Bloomberg for currency rates, then it makes no
difference whether you write screens for cross currency transfers.
Tip 2: Write down all the project risks, and make sure everyone in the team
knows what they are. Mitigate them as early as possible.
Keep it simple
Keep the design of your code simple. Build only what you need now, and avoid
‘future proofing’. Again, this is a change of culture for many developers. Most
developers like to try and design the most flexible solution to a problem that
will future proof them should the user ask for a, b, c and d etc. This is
wrong. Complex flexible solutions take longer to write, are harder to debug,
and the user hasn’t asked for them. How many times have you found future proof
code written which was never used. Think of how JIT (Just In Time)
manufacturing works. You start to build things just in time for them being
required. If you hold stock (over engineered code) it costs time and money to
maintain it. Build the simplest thing that will work. It is cheaper and will be
released quicker enabling you to get feedback from the users sooner.
Tip3: If the users ask for a Mini, build a Mini. Don’t build a Mini with a Rolls
Royce under the bonnet. Keep it simple and build the simplest solution that
meets the requirements.
Feedback, Feedback, Feedback
The majority of money spent on software projects is spent after they have been
released, and are spent on changes and enhancements to the software. This is
due to a number of reasons. One often cited reason is that users don’t know
what they want until something is built that they can use. This is why
prototyping can be useful. [Beware of prototypes too early in the requirements
extraction stage though. Prototypes focus the user too much towards system
requirements, rather than business requirements and business goals.] Still,
getting software released as early as possible, and getting continuous feedback
from the user is key. It mitigates the risk of building the wrong thing.
Tip 4: It is very likely that the requirements will change, so get something out
quick and get feedback as soon as possible. Engage the users as often as
possible.
Know your team
Get to know your team. Every software developer is different. The productivity
rate of one developer could be up to ten times quicker than another. Some
developers are good and enjoy repeatative tasks, others don’t. Some will tell
you the task will take ‘another 5 minutes’, when in fact it will mean a week.
Some will like to build a Rolls Royce when a Mini is required and will take 10
times less time to build. Some will write poor quality code that isn’t fit for
release. Others will spend too much time focusing on fixing minor bugs rather
than moving onto show stoppers. Some developers don’t test their work. And so
on.
Tip 5: Know your team. If you don’t know your team then their ‘surprises’ will
present a risk to your deadlines.
Time Estimates
Most developers do not factor development, build, integration, debugging and
testing into their estimations. To avoid surprises at deadline dates make sure
the developers give you time scales that include the whole life cycle. Write
down their estimates and get buy in from them. Use them to feed into subsequent
estimates.
Tip 6: Make sure estimates from developers include the whole lifecycle.
Refactor The Code
Hopefully you are no longer building complicated frameworks from the start and
are focusing on keeping the code as simple as possible to meet the
requirements. This gives you quicker delivery and mitigates the risk of
building the wrong piece of software. However, you need to make sure that you
also continually refactor the existing code base to avoid it rotting. This
means changing the structure of the code internally, without changing the
external behaviour of the system. You are now evolving the design of the system
along the way, rather than trying to guess the whole design up front. Note
though, that in order to go down the route of evolving design with refactoring,
you really need automated tests.
Tip 7: Refactor your code to avoid it rotting. Back this activity up with
automated tests.
Automate Testing
Show me a developer who always tests their code and I’ll introduce you to
Father Christmas! They just don’t do it. Automating both your unit testing and
system testing makes you develop quicker. You have exhaustive sets of tests
that run quickly, are documented, are standard, and are repeatable. They also
support the refactoring activity. For more on this see my other articles on
Test Driven Development , and Developing
Tests With NUnit 2.0 .
Tip 8: Automate the testing of the application. It massively increases quality
saving you an enormous amount of time having to do manual ad-hoc testing and
debugging. It also enables you to do effective refactoring.
Manage Your Problems
Make sure you keep track of all the issues and risks on the project, and also
track your bugs. Prioritise them and deal with them accordingly. If you don’t
formally log them, they will get lost and you run the risk of not resolving
some important issues raised.
Tip 9: Log and manage the project issues, risks and bugs.
Justify New Technology
Don’t use technology just because it is new. Developers like to open all the
new presents that the market constantly tries to claim as the next silver
bullet. Some new tools are great, but make sure that developers justify their
use in terms of the value they will bring to the project. Being ‘cool’ is not a
business reason.
Tip 10: Use new tools only if they provide business benefit.
|
