{"id":92,"date":"2021-04-16T18:29:12","date_gmt":"2021-04-16T18:29:12","guid":{"rendered":"https:\/\/serioussemicolons.wordpress.com\/?p=92"},"modified":"2021-04-16T18:29:12","modified_gmt":"2021-04-16T18:29:12","slug":"inverting-the-strategy-think-first-development-vs-code-first-development","status":"publish","type":"post","link":"https:\/\/blog.bryant.ai\/?p=92","title":{"rendered":"Inverting the Strategy: Think-First Development vs. Code-First Development"},"content":{"rendered":"\n
\"\"<\/a><\/figure><\/div>\n\n\n\n

There are a million differentiators between juniors and seniors (sidebar: if you’re a junior looking to level up, check out this awesome list of tips<\/a>) but in my experience the biggest one is how they approach the creation of new features. In a nutshell, juniors jump right in and start coding. Seniors think about the problem thoroughly <\/em>and plan their approach before ever writing a line of code.<\/p>\n\n\n\n

Making messes is fun (but risky)<\/h2>\n\n\n\n

Back when I was in college and I billed myself as an “indie developer” (that’s code for junior) my coding style was very experimental<\/em>. I would take a given set of requirements, write a bunch of code really really fast, throw it at the wall and see what stuck, then iterate off of that. Rinse and repeat. And, I have to admit, for smaller projects and scrappy startups, this strategy kinda works. It’s also really <\/em>fun, and it’s still the style I use for hackathons and some personal projects.<\/p>\n\n\n\n

But it’s becoming rarer and rarer that I work on projects that can support this workflow. There are side effects to experimental, code-first development that may not be immediately apparent:<\/p>\n\n\n\n

  1. Rapid coding is a hair’s breadth away from sloppy coding. When you’re coding quickly without much forethought, you forget about important things like security concerns and strict input validation.<\/li>
  2. When coding this way, it’s easy to forget the fine details of requirements and code yourself into a corner without realizing it.<\/li>
  3. And, perhaps the most serious problem of all, this often leads to snafus that make their way up to production where your users can encounter them.<\/li><\/ol>\n\n\n\n
    \"1926:
    Credit: xkcd<\/a><\/figcaption><\/figure>\n\n\n\n

    Now, I’m not perfect, and old habits can die hard. So sometimes I still catch myself developing this way. However, nowadays I’m using a new strategy which I call think-first development.<\/strong><\/p>\n\n\n\n

    Planning is less fun (but less risky)<\/h2>\n\n\n\n

    Here are the principles of think-first development:<\/p>\n\n\n\n

    1. It is essential to understand the entire scope of the problem prior to beginning development. That means all inputs and outputs, edge cases, use cases, and dependencies.<\/li>
    2. Talk about, think about, and ask questions about the entire system <\/em>until you understand it as well as you understand the programming language(s) you’re implementing it in.<\/li>
    3. Documentation of the above two steps is beyond important, it’s essential. If you skip this step and keep all the design information in your head, you’ll forget and fall back to quick-and-dirty.<\/li><\/ol>\n\n\n\n

      Understanding the full problem scope<\/h3>\n\n\n\n

      Ah, the age old question. What problem is this system going to solve, and how will it do that? <\/em>This can range in difficulty from very easy (like coding a login page<\/a>) to incredibly difficult, sometimes impossible for a single engineer (like the Bloomberg Terminal<\/a>). I’m going to skip the part where I explain how I’ve come to understand how <\/em>to understand problem scope, because many have blogged on it and it basically boils down to this:<\/p>\n\n\n\n

      Ask “why?” and if you’re still confused, ask “why?” again. Ask “why?” until you can’t anymore.<\/p>Every three-year old ever, and also smart engineers.<\/cite><\/blockquote><\/figure>\n\n\n\n

      The key takeaway here in the context of this post is this: do NOT write a line of code before you fully understand the problem scope. If you don’t, you’re walking blind into a potential minefield of issues. (experimental code is fine, but no pushes!)<\/p>\n\n\n\n

      Talking about the system<\/h3>\n\n\n\n

      Everybody has a different perspective, and the job of a senior designing a new system is to take all of these perspectives in, discard the ones that don’t make sense, take pieces of the ones that do, and combine them into a cohesive whole.<\/p>\n\n\n\n

      I want to be sure I drive this point home since it’s so important: everybody <\/em>has a perspective, from the juniorest junior to the brand-new BA to the seniorest senior. Now, as may be obvious, there is a lot of lift and noise in involving everyone in the discussion, and often new features don’t have enough lead time to accommodate this level of investigation, so take it from me: the best method for gathering a collective set of opinions is an open forum. <\/strong>Get everybody into a room\/Zoom and start asking questions and generating discussion. Don’t forget to set up follow-up sessions if needed! <\/p>\n\n\n\n

      Don’t write code until every possible avenue has been explored and either considered or discarded. Everybody has an opinion, but a smart engineer knows how to sift through these and come up with a cohesive design plan!<\/p>\n\n\n\n

      Document everything, and document some more<\/h3>\n\n\n\n

      I really wish I could share with you my latest system design document, because it’s really a work of art! Many hours (OK, forty) were put into creating it but it’s client-specific and I’m not in the business of leaking IP. Here’s what I’m going to do instead: below you’ll find a list of the key sections that I write when I create any standard SDD (System Design Document). Each has many, many <\/em>subsections specific to the project or feature I’m designing. Also, images, links, blurbs, pseudocode, anything<\/em> to demonstrate a key understanding of what will be developed.<\/p>\n\n\n\n