ASP.NET Security Consultant

I'm an author, speaker, and generally a the-way-we've-always-done-it-sucks security guy who specializes in web technologies and ASP.NET.

I'm a bit of a health nut too, having lost 50 pounds in 2019 and 2020. Check out my blog for weight loss tips!

Speeding up time to market for software development projects

Published on: 2011-11-30

The days of software taking years to plan and deliver are gone. Modern software teams need to have production-ready projects done in months if not weeks. Since there are relatively few articles out there on how to do this, here are some things that you can start doing today to start delivering business value to your users faster and more reliably:

Understand the business need and the user

It is odd to talk about improving software development turn-around time and start with talking about something that isn't related to writing code, but one of the biggest problems that I see with project overruns have to do with understanding (or lack thereof) of what's needed from a business perspective. If the software team doesn't have a thorough understanding of the business problem at hand, significant delays and unexpected rework can occur and miscommunications are found. If the software team understands the business' wants and needs before they start, they 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. However, 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 by putting in something simple and change later on based on feedback if needed.

Use development frameworks 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 usually 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.

This article was originally posted here and may have been edited for clarity.