Written by 
Let me tell you a story about when I cut months of work off of a project.
Part of Rheaply’s offerings is an inventory management platform. A major problem customers run into is data entry – name & description is not enough, we need colors and manufacturers, dimensions and weights, etc. Accurately filling in the data for thousands of items is painful.
One idea we had to alleviate this problem was to create a product library – pre-vetted information about common products that users could autofill.
When we first set out to write a product library, we thought we’d have to spin up a new, internal platform – a prospect that would take months of work. But then I had an idea: we already have an inventory management platform. What if the product library is nothing more than a special organization on our pre-existing platform?
We still had to write some APIs for accessing the product library, but this idea took a multi-month project down to just a couple weeks of work.
The story above illustrates an important aspect of software development: it’s an extraordinarily nonlinear practice. I didn’t save time by working hard – I saved time by finding a different route to the goal that was much, much shorter.
Writing code faster or working longer hours is not the fastest way to get a project done because you can only linearly scale up how fast one can program. On the flip side, there’s nonlinear savings that can be had by reducing the amount of work you need to do in the first place. Thus, you should write less code rather than trying to write code faster.
Here is a non-exhaustive list of ways I’ve found to drastically cut down development time:
Pare down requirements – Do you really need to do everything you were asked to do? What about the parts of the feature request that really, really suck? Negotiate to do less! A lot of managers will accept a pitch like “if we skip adding push notifications for this feature, we’ll cut down dev time by 50%.”
Better code design – Don’t automatically go with the first implementation that comes to mind. Sit down and think about the best way to solve a problem, or write a couple prototypes. You will come up with an implementation that’s much simpler/smaller than you initially thought of. (This seems counterintuitive because you’re spending more time upfront, but in my experience this prep work pays off dividends in the long run.)
Maintainable code – Almost no code is written once and never modified again. It’s a long con, but code that’s easy to modify later will save you tons of time. (On the opposite end, I’ve seen codebases where things have gotten so hairy that it’s nearly impossible to make forward progress without tons of refactoring first.)
Code generation / automation – You don’t have to write all the code – computers can do some of it for you! Instead of writing boilerplate over and over, make the computer generate it for you. Automate your processes (like building/packaging/releasing) so that you don’t need to spend time on repetitive tasks.
Ask questions – No one knows everything, even you, dear reader. (Sorry.) A good question, asked early, to the right person, can unlock doors. Maybe you’re dealing with a new part of the codebase you’ve never touched before – a 15-minute rundown with a coworker can save you a day’s worth of exploration. Or perhaps you’re stuck on a problem – instead of banging your head against a wall, ask someone else to walk through it with you.
When I was implementing offline mode for Trello Android, I had to come up with some way to coordinate IDs for locally generated models vs. the server’s IDs. My first few attempts were failures – which is to be expected! No one is perfect. But I spent much longer on these failed attempts than I should have. Why? I started implementing the easy part of it – rote work that took over a month. But when I moved onto the hard part of the solution, I realized my solution was infeasible. If only I’d figured that out before I spent a month on the easy part of it!
Sadly, the nonlinearity of software development cuts both ways. As much as you can cut down dev time with good tactics, you can also balloon development time by creating much more work than needed. In the worst-case scenario, you can actually do negative work by writing many bugs and merging code that’s never used.
Here’s another non-exhaustive list of ways to try to avoid taking up too much time:
Prototype – I almost never get the code design right the first time. Writing a quick, throwaway prototype lets you get the feel for the right solution to the problem. Instead of going down the wrong path for too long (as I did above), you can swerve around roadblocks.
Understand requirements – Feature requests often play a game of telephone: customers -> sales -> product managers -> engineering managers -> you. By the time requirements get to you, they may be a garbled mess, and you can end up building the wrong feature or something that’s way bigger than needed. Before jumping into a project, make sure you really understand why the feature was requested so you can match the solution to the actual problem.
Find the root cause – Before I fix any bug, I try to figure out exactly why it’s happening. Otherwise, you can end up hacking together a “fix” that doesn’t actually solve the problem, or creates some new bug elsewhere. This practice is hard to embrace, especially if the servers are on fire, but accidentally adding fuel to the fire is so much worse than slowly putting it out.
Stable tools – How many times has this happened to you: you login to your computer, ready to tackle a problem, only to discover that your build is broken, the artifact repository is down, or CI is failing randomly. Instead of getting any work done, you spend half the day just getting to a state where you can do any work. Spending time on stabilizing your toolchain will save all your company’s devs gobs of time down the road.
Here’s a general-but-related piece of advice: take care of yourself.
Exercise. Eat well. Get sleep. Hang with friends. Do hobbies. Whatever keeps you mentally charged.
A happy, fresh mind comes up with great solutions. I’ve often clocked out at 5PM, frustrated with a problem I can’t solve, only to get to work the next morning and solve it in minutes.
This is one of the many reasons I don’t believe in long working hours. Why would you fruitlessly work a few more hours on a bad solution when you could rest, then come back with a much more expedient solution the next morning?
The goal of software development isn’t to write code; it’s to produce software. Don’t simply take your first solution and barrel down mindlessly on it. Focus on the software you want to create and you’ll get there faster.
Do you have other ways you’ve drastically cut down on development time? Share in the comments below!