CIO
11 ways to accelerate your software project
By: Peter Wayner
Sure, every IT leader and customer wants every software project delivered faster. But fast-tracked development can lead to buggy code, shoddy testing, incomplete solutions, or worse, insecure software. But, while no one wants a failed software project, sometimes certain contexts — market conditions, business needs, windows of opportunity — can justify some measure of tradeoffs in favor of speed.
Software development is not just a logical endeavor. It’s also an art and an integral part of many organizations’ business strategy. Somewhere within those overlapping facets lies the possibility to tune a more efficient development process, if done effectively, fairly, simply and safely. You just have to know the tradeoffs and make decisions that favor streamlining the project over developing the perfect software dream.
Here are 11 strategic decisions IT leaders can consider when seeking to accelerate a particular software project that needs to move quickly.
Control stakeholders’ dreams
Everyone wants input, and stakeholders from the marketing team, shipping department, and accounting all come to the conference room with big dreams. The trick is to find the dreams that are the simplest to fulfill. In one miracle of meetings, my software team discovered that just adding pre-fill default values to one form field would save the data wranglers millions of hours of work. There were hundreds of sales agents filling the form out from scratch thousands of times a day. A few extra characters in the HTML and we were treated like geniuses.
Keeping stakeholders’ feet on the ground helps control of a project’s scope. If you can focus stakeholders on features and improvements that are smaller and of very high valuable, the check boxes will be filled in much faster.
Stop developers from dreaming big
But it’s not just the suits that can get carried away. Developers also need to keep their feet on the ground. For every bullet item on the project list, a developer will see it as a chance to finally try some buzzword that’s clever, new and incredibly time-consuming. Are two columns out of alignment on the screen? Now is the time to rewrite the entire stack in pure functions implementing multi-gradient power descent optimizing quantum learning algorithms.
While developer enthusiasm is often vital to achieving an accelerated timeline, ensuring that enthusiasm is channeled toward the streamlined goal is paramount.
Cut features
Slicing away at requirements seems like a lazy man’s game. After all, it’s easy to get everything done faster if you redefine “everything” to be a smaller set.
But sometimes it’s necessary and useful to focus the team. The artful approach is to make sure the foundation is still solid enough to handle the skipped features in the future. For instance, make sure the database schema anticipates some of the enhancements that someone wants to add in a later iteration. If it just means tweaking the schema a bit now, you can also save time when you return to features you held off on this go around.
Streamline testing
One of the challenges of deploying code is testing it before it goes live. Lately, the trend has been to break everything into smaller projects that can move independently. If each project must be tested independently too, well, that means much more testing. Some of the new microservice architectures filled with dozens of microprojects must be tested dozens of times.
You can’t get rid of the need to test, but one trick is to test multiple projects that work together at the same time. Sometimes bundling together several parts can eliminate the need to test them independently.
Simplify the architecture
If you’re going to be cutting out features and leaving some work for later, sometimes you can rethink the architecture at the same time. Sometimes not.
If the features might come back next quarter or even next year, you better leave the foundations in place. But if they’re not essential, it can be extremely liberating to clear away big chunks of the architecture.
Dial back performance guarantees
When times were flush, everyone wanted answers in milliseconds while ensuring data was replicated into three geographically separate data centers just in case a hurricane and an earthquake hit simultaneously. Who doesn’t want perfection?
Generally, high performance means lots of extra layers of caching, load balancing, and replication and those extra layers take time to build, configure, debug and maintain. One of the simplest ways to cut time from development is to convince stakeholders to be willing to relax if a screen takes a bit longer to refresh or — perish the thought — a few of their bits disappear in a glitch. Not every project requires as much precision or reliability as brain surgery.
Leverage existing code
The easiest way to spend more time is to explore a new technology. Yes, it’s important in the long run to invest in the next generation, but the time for that is not when someone is pounding on the table asking for faster completion. Using the same language and database that you used for the past dozen projects will be faster and simpler. You’ll move faster and sometimes there are chunks of code you can reuse. Not only that, but you’ll be maintaining a consistency that makes it easier for developers to move between projects.
Embrace technical debt
Developers like to talk about “technical debt” when they want something to be done. By committing to a limited or quick solution now, developers can leave the work of fixing or filling in the gaps to the future. It’s a real concept that’s important to consider, but sometimes people invoke it when they want to manipulate the process.
Some technical debt is okay. Using the latest databases or the newest language technology is not always necessary. Sometimes it’s possible to skip three or four generations of some miracle technology and go right to the newest version. Leap-frogging can save plenty of headaches and late nights in between.
There is an art to this game and it’s not without some dangers. But many times the specter of technical debt is much worse than the reality of skipping a few generations of updating.
Open source
Too many projects have too much custom code in them. If you’re trying to accomplish something, there’s a good chance someone else has the same headache. Sometimes that other person or organization has started an open source project and now is your chance to join forces.
Open source isn’t a panacea. There’s no such thing as a free lunch. You’ll often need to make compromises and work with other teams to converge on some code that works well for everyone. When the process works well, you’ll only spend a fraction of the time contributing to the open source project and everyone will prosper.
Use basic tools
Many projects can be accomplished with off-the-shelf tools. It’s amazing what can be constructed with a standard web form from, say, Drupal, Google Forms, or Survey Monkey that dumps data into a spreadsheet that does the analysis. It’s not slick. It might not even be called “coding” by the Programmers’ Defense League. But if it delivers the answer in a way that is reliable and reusable, it may be the fastest way to accomplish a big development project.
Be realistic
All of us dream of building a website that goes viral and so we plan to handle the most extreme load. I’ve watched careful architects describe their three-tier systems with load balancers and replicated databases everywhere all to support a project that might take care of 100 people a day. It wouldn’t be an issue if scaling gracefully were easy, but adding these layers increases the complexity of the project, draws out the construction, and complicates the maintenance. Bringing in new programmers is that much harder and fixing even the smallest issue can require long team meetings. It is true that some of the newer serverless tools such as the Google App Engine make scaling simpler, but there are tradeoffs in complexity and cost.
Good engineers anticipate weird problems that could come down the road. But good cost engineering requires being realistic about the odds and, perhaps, deciding to accept bad performance or even failure when these outliers strike.
