Death by Coding
People, Process, and Planning in Software Development
In a recent conversation with Webapper, a lead developer said “In order to ship on time, I just need more time to code.” He went on to say “If I didn’t have to spend all this time on the product roadmap, I could ship on time.” After three decades in software development (yes, get off our technology lawn!), these statements sound three significant alarm bells. Atop the list of concerns is the use of “I” when there’s a large development team beneath that developer. Good process relieves heavy effort. In addition, there’s the dismissal of a formal development plan. We have lived through death by coding (does that make us ghosts?), so today we’ll outline the importance of people, process, and planning in software development.
One Is the Loneliest Number
As you may recall from our treatise on Single Points of Failure, there are significant risks to having a solo (cowboy) developer. Even if the CTO/lead developer is brilliant, she needs to share that wisdom rather than horde it. The challenge of having so much tribal knowledge locked in one skull is overwhelming. We see it far too often. On one project, we’ve worked with the original developer of a complex custom e-commerce solution, and his manager told us there may as well not be any documentation (because what he had ever delivered was incomplete and inaccurate). Twenty years later, the company is trying to solve that problem. On another past project, after we completed our engagement, the CEO called in a panic because his lead developer had gone AWOL somewhere in Asia.
The warning signs here are language around “I” versus “we” and “my” versus “our”, and concerns over one person being indispensable. If you see these symptoms, you have a potential SPOF. Start with some homework about pair programming…
Everybody’s Workin’ for the Weekend
We hear it all the time “Don’t work harder, work smarter”. You can’t just put the nose to the technology grindstone and crank out the best solution. And if there’s one thing you’ll hear in almost every Webapper conversation, it’s the importance of process. As a small team managing many large projects, we regularly invest in tools and process. If someone brings a better tool or an idea to improve our process, we look & listen. From ideation to source code control to DevOps, we’re entrenched in process. We mock up designs using Balsamiq and Miro. We track requests and work with an integrated ticketing and source control solution. We have daily stand-ups, and Google Workspaces is our communication hub (and we have protocols in how to communicate best). You know what we do for a living? We design & build cloud SaaS solutions for a wide range of industries for small to mid-size (and occasionally enterprise) organizations. We could not possibly manage our business by working harder. The house would collapse. Oh, and we iterate all the time with a tight internal feedback loop.
The warning signs may appear as extensive coffee bills, weekend coding projects, or team stress & burnout. Software developers need a manageable rhythm to do their best work. Good process, like agile development cycles, reduce time-to-market, improve quality, and boost team morale. Modern tools help with process, although pen & paper or Google Docs are tried and true.
We’re On a Road to Nowhere
Yogi Berra is credited with saying “If you don’t know where you are going, you’ll end up someplace else.” And software & technology projects are no different. In fact, a roadmap in technology defines success. Stakeholders determine what they want or need, and the software roadmap prioritizes delivery. The product roadmap offers a glimpse of the vision, direction, and progress of a product over time. We recently released our own SaaS product called CloudSee Drive [https://cloudseedrive.com]. It originated as a bolt-on request of CloudSee [https://cloudsee.cloud], but we quickly realized it needed its own roadmap. And as we got going, we realized that the serverless cloud native platform we built would probably be the new home of original CloudSee. We’ve launched our software, and as we listen to feedback from users, we’re collating ideas on what to do next. We have years of plans already!
A lack of documentation or project/product planning is a signal there may be a problem, as is the lack of deliverables (timely or not). Yes, it’s challenging to keep product roadmaps updated, especially with agile teams (that have tighter feedback loops), but the goals should be reviewed and adjusted regularly anyway. “This quarter, we want to release X” and “This year, we need to finish Y” are guideposts for a product. Did you release X? Is Y finished, and if not, what’s left? What happens after Y is done?
People, Process, and Planning in Software Development
Putting it together, if you see these signs, you’re probably neck deep in technical debt. You’re not alone. Virtually every organization has it (and if they say they don’t, they’re probably in denial). Technology moves quickly. Technical teams have budget limits, time & skill constraints, and growing demands. But you can work to reduce it over time. Let’s look at the three dials you can turn. First, open conversations with your team about technical debt. It’s not about pointing fingers, but identifying areas to address in the software lifecycle: gathering requirements, system architecture, prioritization, programming, testing, deployment, and technical support. Your team should be stakeholders in finding solutions to the issues. Second, emphasize that effort alone isn’t the answer. “We need better testing” may mean adding processes and tools, not just staffing. “There’s no clear roadmap” may be caused by a communication breakdown. Identifying problems, then addressing them will invigorate your product from the inside out. And third, emphasize knowing where you’re going. Sharing the vision, dividing the work into meaningful & logical segments, supporting the vision with resources, and then holding the team accountable is a roadmap to success.
Death By Coding
Unsurprisingly, we want the takeaway of what we share to be that death by coding is not a viable solution. Your people matter. Your processes enable them to do more in less time with more repeatability. And most importantly, your planning is an organic, shared process. Together, they save lives… So when your office is low on coffee, you find pillows hidden under desks, and tempers are flaring over missed deliveries, read over all these ideas again.
Leave A Comment