So we’re moving along steadily through our Web Design & Development Process series. We’ve covered Aggressive and Invested Requirements Gathering, Relentless Ideation, and now we’re moving into what we call Atomic Preparation.
The idea here is that one idea is actually many ideas. Software concepts are complex and the key to solving complexity is break the concept apart into modular - or atomic - components. They are small pieces that can be easily isolated and understood and then organized into a larger working mechanism. Think of organs in the body. They have a particular function, yet are made to work in context of the whole. This is the same thing.
Let’s look at this from two angles.
Breaking apart the concepts
The best way to demonstrate this is to use a real-world example. Let’s pretend that you need to support embedded digital eSignatures on your web application and you’ve chosen to use HelloSign. Well, that maybe sounds doable but is also tough to grasp because there’s a lot involved in the full digital signature process and who knows how much effort that entails. So if we spend some time looking at what’s involved with digital signatures with HelloSign, we learn that the following pieces are needed.
- Authenticate to HelloSign
- Generate a new eSignature Request
- Embed an eSignature Request
- Cancel an eSignature Request
- Get eSignature Request Details
- Process eSignature Events via Callback
Ok, so there’s a lot here, but it’s digestible and you can start to think about the pieces needed to pull this off. You can start thinking through the particular questions each piece raises as well as a sense for the scope of work involved. It’s much easier to form a plan now than just thinking about the whole picture and what it might entail or “gut feeling” what this type of process might look like.
Breaking apart the work
The same principle applies to the work itself. We have made it a real priority at Ashday to break work into small components, often no larger than about a day of work for one developer. Why? Well, traditionally when things slid over the cliff on us it was usually singular larger efforts that had been estimated at too large of a scale and built in isolation. So sticking with our example above - an 80 hour HelloSign integration single ticket was much more likely to suffer from “I think I’m getting close” or “This isn’t going well” after already being halfway through the budget and timeframe. Breaking it down into a dozen or so 2-8 hour tickets is much more successful because it allows for frequent peer review, which we’ll talk about later in the series, and a very quick cycle of feedback. It’s also just plain easier for developers to understand what they’re building because you’re asking them to focus on 5 requirements at a time instead of 30. So in the moment, you may just be worried about a real solid solution for authenticating to HelloSign, and appropriate error handling, but you’re not also constantly juggling all the other elements involved in the project.
This approach is also coupled with smaller files and smaller functions too, which means a much nicer version control experience and a much more digestible - and maintainable - application. Breaking things down just simply helps on almost every level. Big wins all around.
Yeah - so basically just break it down. Break it all apart. Make life easier on yourself and your developers and find out right away when things are drifting off course. It’s the only way to go.
The next piece in this series moves into the build phase, starting with Torrential Communication - a somewhat exhausting but totally rewarding and vitally critical component of running your development project.