Monthly Archives: January 2013

Developing Successful Software Projects (S.T.A.M.P)

A large proportion of software projects are still failing costing billions each year and so the need to engineer solutions correctly has always been of great importance, yet there doesn’t seem to be a silver bullet approach to developing software that will always end in success.  If I’m honest, I don’t think there can be, what with the constant changes in technologies, skills, tools, platforms and devices we often find ourselves as developers in a world that is changing faster than we can keep up.  Imagine trying to build a bridge over a river that was always widening or narrowing and finding that your materials or tools were ever changing as the bridge was being constructed.  It’s a very difficult engineering discipline to be involved in but also an exciting and challenging one.

When I first started in the profession of software engineering I loved coding but I didn’t understand how to develop a successful project.  I’d get a vague requirement from a customer and jump straight into the code in order to implement the solution as I saw it.  15 years later and after working on multiple projects, some failures, some successful it got me thinking.  What have I learnt with regards to writing successful projects?, in fact what makes a successful project?  I then started to think, if I was starting a new project, and knowing what I know now with regards to why projects failed in the past, what basic principles, do I feel must be present for a project to stand up good chance of succeeding.

Based on my experience I came up with these 5 basic principles.

My basic ingredients for a software project

My basic ingredients for a software project

Now you may not agree and with different experience comes different viewpoints but this is great as I hope this post will lead on to further discussions and ideas as to: what are the ingredients for a successful software projects?


Stakeholder Driven

I’ve seen a lot of projects where the stakeholder will come to the developer(s) with a requirement. The development team will then formulate their own understanding of that requirement or feel they can offer a better return on the original requirement by driving the development with little input from the original stakeholder.

We have all seen the classic comic strip:




The driving force behind a project should always be the stakeholder (whether that’s the customer, business, or any entity that requires a solution to the problem) guided closely by the development team.

Agile teaches us to use User Stories (a short statement which captures the ‘who’, ‘what’ and ‘why’) to help the stakeholders convey the functional business requirements to the development team.

This is great, as the User Stories allow the system to be broken down into smaller chunks and encourage the developers / analysts to work with the stakeholder to refine and detail the requirements.  Communication is improved and the stakeholder will have more confidence that they will receive a solution that closer matches their initial requirements.

If we consider SCRUM, requirements are broken down into sprints (normally a period of one-month or less which will result in a ‘Done’ and use able product) which implement part of the final solution.  Stakeholders should ideally be involved when reviewing the results of a sprint in order to ensure the requirements are being realised as they envisioned and to recommend changes or introduce new considerations due to a changing business or environment.  If a software project was not driven by the stakeholder in this way, the developers are likely to misinterpret the requirements, or the business is likely to change during the development cycle so that the end product no longer completely meets its needs.

A great advantage I’ve always seen from using the SCRUM approach is that the Requirements offering greater Risk or a greater ROI are handled first.  This can result in a use able product which meets the stakeholder’s needs earlier and as such the entire budget may not be required if the product is ‘good enough’ or additionally, the customer is more likely to have a working project if the budget is reached before the end of the development.

Testable Code

One of the key by-products of going down the Agile route is the Re factoring of Code.  Unlike the old waterfall models, Agile actively encourages change.

As Agile software professionals, we are encouraged to develop sprints of work which can be reviewed by the stakeholders.  This is great as it allows testing in parallel with development reducing the overall time for the project life cycle   However, this will almost certainly result in the re factoring of existing code as customers detail and finalise their requirements or the solution is re factored to adjust to the ever changing business needs.

Now as developers I suspect we have all been in that situation where the re factoring of an area of code has resulted in another area breaking.  However, by writing testable code and applying unit tests for example, we can feel confident that we will be notified of any breakages due to the changes we make.  As a result we deliver higher quality software which is easier to maintain as well as the time in QA and testing being reduced.  By writing testable code we promote good software practices such low coupling, high cohesion, code re-use and hopefully employing ideas such as unit testing and dependency injection.


Accept Change 

Often overlooked, but in my mind a key ingredient to delivering a successful software project is the ability to design a solution which can adapt to change, whether this relates to changes in the requirements, design or even the environment within which the solution is deployed.

A common mistake is to receive a set of requirements and dive straight into coding a solution without entertaining the idea that requirements may change or even the business needs may change leading to the re factoring of code.  Now this is where the experience of the developer comes into its own.  Developing a solution that fulfils the principle of low coupling, high cohesion and can be extended and modified in an easy programmatic manner takes real skill.

If we don’t accept that the software is likely to need to change with future enhancements then we must accept that maintenance and complexity costs are going to increase in order to implement future modifications and enhancements leading to larger development time, lower quality software not to mention lower customer satisfaction.

Looking back, every company I have worked for have been involved in the development of at least one long running project and most of those have suffered from ‘Software Rot’.  Many of the projects where designed with a single implementation in mind with little thought of future re factoring and change requests.  The result was normally quick hacks to existing code rather than expensive design changes.  With this dis-regard for good design came messy, in-efficient and un-maintainable code i.e..  ‘Software Rot’.   Eventually the solution will no longer meet the needs of the business.  This can lead to a break down in the moral of the develop team as essentially they will be working and maintaining a system which they are not proud off and desperate to re-write.  Something which is not always possible due to the expense and time involved.

Measurable and Transparent Development

How can we determine if a project is on track? After all if there are obstacles in the way or deadlines are slipping then these need to be addressed as soon as possible.

Frameworks such as SCRUM go some way to solving this issue.  A project backlog is created as a single source of everything that is required in order to implement a workable solution.  Items are selected from this backlog and arranged into sprints of work (no more than a month), each resulting in a “Done”, useable and potentially releasable product.  During these sprints there are short morning meetings to check progress and remove any potential obstacles.

Taking this approach to software development allows all stakeholders to have a clear picture to what is required and the progress is clearly visible and measurable   It will also improve communication and confidence among the stakeholders as well as the moral of the development team by returning a regular sense of achievement and progress to the development cycle.



And finally, when it comes to producing quality software, on time and to budget there is no substitute for good planning.  After all, like a friend once told me

If you were going to scale Everest you would plan first to give you the best chance of success, so why should writing software be any different.  Don’t jump straight into the code without planning first it will not end in success’.

Again, good planning comes with experience.  For example, take the common scenario of the initial requirements being finalised and entered into the project backlog.  Now at this stage your manager may appear and say ‘right I need to price this project so how longs it going to take to develop?’  Developers hate this, as at this stage there is insufficient detail to time each requirement accurately and more often than not they are held accountable to the estimates given before the project commences.  A common and difficult situation.

However there is a solution.  Sometimes known as Planning Poker the basic premise is that we as developers stop trying to estimate requirements as time-scales but rather as degrees of complexity compared to a known entity.  In other words, using a past piece of work as reference, and knowing how long it took to implement, we can estimate how complex we feel new requirements are as opposed to this original piece of work.

The Poker element of this approach helps with the accuracy of the estimates, after all more heads are better than one.  So take the following made up complexity scale – 2, 4, 8, 16, 32, 50, 100.  With a requirement on the table all developers give an estimate from the scale.  One developer might say ‘2’, one ‘50’ while the others settle on ‘8’.  This is great as all developers have different strengths and experience and might pick up on things that others other look. The point is, the reason for the ‘2’ and ‘50’ would be discussed before entering into a new round of estimates.  Hopefully with each round of discussions, points are raised which lead to more similar estimates by the developers until an accurate idea of the complexity of a requirement is known.

Good Planning should also mean good design.  With the surge of multiple platforms and devices on which software must operate rising, never as this been more evident.  What environment will the application be deployed into?, what is the topology? Are there performance requirements? What are the potential obstacles?  Will the application need to be scalable? Cloud or Internal Hosting etc.   All these questions need to be asked, planned for and built into the design if the solution is to be truly successful.

Planning is always going to be my main ingredient for a successful software project as from experience, whether using the traditional Waterfall approach or the newer Agile approach, the successful projects I have been involved with have always been planned properly.  Remember the well-known phrase;

‘Failing to Plan is planning to fail’