Speeding up time to market for software development projects

In order to meet the ever expanding needs of business, technologists need to shorten their delivery times.  This is no less true in software development projects.  Perhaps I’m looking in the wrong places, but I’m seeing a lot more articles on the need than ways to meet that need.  So here are some things that you can start doing today to start delivering business value to your users in a timelier manner:

Understand the end user

You may find it strange that my first point about delivering software more quickly is to add more work to the development team.  However, a significant cause of time and cost overruns in software projects is the constant need to implement desired features without understanding the underlying needs.  If you understand the wants and needs of the end user before you start, you will be able to design a better software system the first time, significantly reducing the need for costly rework.

Right-size the development team

Don’t assume that adding more people to the development team will proportionally decrease the time-to-market of the software product.  When a team grows from one to two people, you double the number of people needing to understand the requirements; you double the number of people needing to know about changes, you increase communication issues due to the development team needing to understand each other’s code, the need for project management increases, etc.  Smaller teams are more agile, so keep teams as small as reasonable to achieve the desired results in a timely manner.

Right-size the development effort

Larger projects require disproportionally more effort to keep the code base easily maintainable.  If you do not make the effort to keep the code base clean on large projects (if your team is made up of unskilled developers), the result will be a tangled mess that can will always be too buggy to be shown to an end user.  Conversely, if you build your small project as if it could scale to easily handle a team of tens of developers and millions of users, you are certainly wasting time and money fixing unneeded scalability concerns.

When in doubt, start simple

Complex features lead to a disproportionate amount of effort, both in clarifying the business requirement and in creating an appropriate solution.  If the complex solution is the appropriate one for the situation, then put it in, you’ll save time later.  If not, put in the simplest solution that minimally meets the business requirements.  If your solution is complex, it is likely a sign that something is not understood (and it could be misunderstood by the development team, the business stakeholders, the end user, or any combination of the above).  If you don’t understand it, then it will change later.  Save time and money now, and change based on feedback if need be.

Use development tools whenever possible

I’m a big fan of using development tools, whether they are libraries such as JQuery, frameworks such as NHibernate or CSLA, or a hand-rolled tool like a JavaScript generator I made a couple of years ago.  These tools are often made by developers, for developers, and speed up development time considerably.  Many good developers out there disdain these tools because they are inefficient and inelegant, but the minor losses in elegance and execution efficiency are more than made up by the gain in ROI.  These developers need to remember that their job is to deliver working software as efficiently as possible, not deliver the cleanest code base possible.

Be careful in choosing third-party frameworks/plugins

And by third-party tools, I’m thinking of CMS systems, eCommerce systems, or user-interface control libraries.  Essentially, be wary of anything that promises full features out of the box.  These tools are great if and only if you are planning to use features exactly as they’re intended to be used.  Modifying these systems is often more trouble than it’s worth.  Most of the time, these tools are crammed with mostly-functioning features, rather than focusing on providing a few completely functioning ones.  The costs updating and maintaining features built with these tools can easily surpass the costs of creating and maintaining the same functionality built from scratch.  I’m not saying that you should avoid these tools, I’m just saying that you need to think twice before trying to bend them to do something that they weren’t explicitly designed to do.

Push your boundaries a little bit each project

Technologies available to create applications faster, better, more reliably, etc., are being created every day.  It can seem overwhelming at times to see how many new tools are available to evaluate.  I can’t speak for all developers, but I can’t get a good sense for what a technology is and is not good for without starting using it in a live-fire situation.  Starting a new project depending on entirely new tools is a recipe for disaster, but starting a new project with no new tools is a recipe for obsolescence.  Each software project you encounter, try something new.  Keep the scope small to keep the risk down, but keep the effort meaningful.  By constantly evaluating new techniques, you are putting yourself in a position to deliver greater value in the future.