Breaking Software Development Into Stages
How to build it step by step.
Welcome to Developing Skills - Skills for Developers looking to develop their careers.
This week we have:
Tip of the week: Breaking a Software Project into Stages
Book of the week: The First 20 Hours: How to Learn Anything Fast
Finds of the week: Satisficing vs Maximizing, Building software with ChatGPT and Searching GitHub.
Tip of The Week: How to break a software project into small achievable stages when developing from scratch.
Here is the approach I often use Worked through an example of building clone of Redis:
Sketch out the vision - what is the application going to do at a high level, i.e. I’m going to build an in memory data stores.
Break down the application into building blocks - As it is a server, I might decide that I’ll need a ‘block’ to listen for client connections, another to handle each connection, one to serialise/deserialise the messages, one to handle the protocol and lastly some form of data store.
Build the core of one or more of the fundamental blocks using test driven development - For example if I’m building a Redis clone my first step would be to write a set of tests focused on handling the protocol. Then I’d develop the code to pass those tests, completing the ‘block’ that is my protocol handler.
Build a walking skeleton - once I’ve built any fundamental blocks, I like to build a walking skeleton. A walking skeleton is a tiny implementation of a system that performs a very small end-to-end function. For a Redis clone that might be building just enough to handle a client connection request, parsing an incoming message and handling the simplest possible command: PING.
Flesh out the functionality - Once I have a walking skeleton I start to add flesh to it. Adding more end-to-end slices of functionality by writing tests and then the code to pass them, for the minimum functionality I will need for each block, to deliver the end-to-end slice. Repeat until all the functionality is there.
Refactor - This isn’t really step 6, I tend to refactor as I go. As the software evolves I will have to change things that were done to enable the development of a walking skeleton (i.e. I might not handle concurrent clients when I handle PING). I will also refactor as I gain a better understanding of the challenges and my design evolves.
For other systems my approach might change in small ways, but these are the fundamental high level building blocks of my process.
Want to Level Up Your Coding Skills?
I believe the best way to do this is to build real-world applications. For that reason I write a weekly newsletter sharing Coding Challenges.
The coding challenges are all designed to walk you through the process of creating an application and to be less than 8 hours work.
Each challenge has you focus on building real-world software rather than toy applications or algorithms and data structures.
You can tackle the challenges in the programming language of your choice. You can even tackle them in several different languages if you prefer.
You can see the challenges and subscribe on the Coding Challenges SubStack.
Book of The Week: The First 20 Hours: How to Learn Anything Fast.
In this book Josh Kaufman breaks down how to get over the painful hump at the beginning of a new learning process. As he puts it’s “Feeling stupid doesn’t feel good, and the beginning of learning anything new is feeling stupid,” - so far too many of us quit during this early learning period.
He outlines for steps that can help:
Break down a skill into it’s components.
Learn enough to know when you’re making a mistake.
Remove any barriers to practice.
Practice for at least 20 hours.
All of which works best if you focus on learning one new skill at a time.
Share(s) of the Week:
Satisficing vs Maximizing - https://longform.asmartbear.com/maximizing/
Building software with ChatGPT -
The Technology Behind GitHub’s Code Search - https://github.blog/2023-02-06-the-technology-behind-githubs-new-code-search/
