Since I joined Unosquare, my co-worker Tom DiGati has been hounding me to write up a post for our blog. I suck at writing, so it takes me a while to do these things. I politely deferred (aka, blew him off) until his promises of eternal gratitude, friendship and agreeing to ride bikes whenever I wanted (you owe me, Tom) changed my mind. So, I sat down to labor over words that had been rattling around my brain for a while. This post is representative of the experiences I’ve had over the years creating products, services, and apps.
While it’s true that software development or product delivery isn’t rocket surgery (unless you’re a part of SpaceX or GE Healthcare), there are a few, slightly better ways of doing things in my humble opinion. Without any further blathering, I submit Part 1 of “8 Dos and 2 Don’ts of Software Development” guide. Because why write one long blog post when you can cut it up into two shorter ones?
DO
Start with “Why”
Most people have an opinion on where to begin understanding a problem or opportunity. I prefer Simon Sinek’s Golden Circles of Why, How and What to help “nail the vision” of your project or product. How to accomplish it and what needs to be built or delivered flows from that like a river to the sea. When you nail the vision, it becomes the cornerstone to the many questions that inevitably occur in most projects. Everyone on the team should be able to describe the gist of why, how, and what the same way (in their own words). Getting people on the same page early on goes a long way toward mitigating misunderstandings and also empowering people to make decisions to move forward without needing to double-check with someone else.
Clearly Define Roles
Openly state who is playing which roles. For instance, every project needs to have a Business Analyst (BA), but for some projects, the Product Owner and BA are the same person. Every project needs to have someone paying attention to the schedule and tasks; sometimes they’re a dedicated Project Manager or Scrum Master and other times they’re not. Every project needs to have an Architect. Sometimes the project has enough complexity to need a dedicated one and other times it only needs a Lead who can also design systems. When everyone knows who is doing what (or who is supposed to do what), communication is cleaner, and coordination is easier. Otherwise, it’s ‘who’s on first‘ again?
Break Things Down
Break things down into small pieces. It is easier to describe and understand smaller chunks of information when there are a lot of moving parts. Small pieces lead to small changes. With incremental changes, it can be easier to conceptualize how and where they fit into a codebase. Larger changes tend to be harder to estimate since they often hide boundaries and gaps in information. Smaller changes tend to be built faster and documented better since there is less to cover. Better documentation and concise, accurate pull request descriptions can lead to better test plans and execution leading to a faster and cleaner delivery.
Draw Pictures & Write Words
It doesn’t matter where or how you create a roadmap, be it by specialized software, a Trello board or a set of PowerPoint slides. As long as a viable mind-map exists, is regularly updated, is published, and your team knows where it is, it’s perfect, no matter the format.
Whiteboard sketches and Polaroid pictures? Check. Photoshop mockups? Sure. InVision prototype? Awesome. All of those plus a 2.5-pound requirements doc with a table of contents and index? WOW. Chances are any given project will land somewhere on that spectrum, and if you’ve done steps 1-3 you can trust the team is documenting things appropriately.
DON’T
Attack the Small Stuff First
My advice is to address your architecturally significant use-cases first which is a fancy way of saying, find the critical, risky, gnarly stuff and attack them up front. This approach may sound like a “time-suck,” but I think the reasoning is sound. The team could aim for traction first and get momentum by checking off the easy stuff and all that. But the trouble is, if you delay the hard stuff, that new idea, you could miss the essence of your project. Everything you intended could end up being completely infeasible. Then, you risk blowing up the schedule, budget, or both. Also, by attacking your complexity first, even in just a design sense, you can better inform the overall approach, estimates, and schedule.
IN CONCLUSION
By now you’ve probably received two text messages, 4 Slack DMs and seven new emails. You’ve probably opened four more browser tabs, so I’ve most likely exhausted your attention span. Let’s end this software development guide here, with three more Do’s and 1 more Don’t saved for next week.
