Atomic Development

TL;DR

Be warned! This is a long article. It takes the principle of "commit little and often", builds on it a bit, and calls it Atomic Development. But I hope you'll feel it's worth your time as it provides some rationale as to why small steps are better and some suggested good practice.

Introduction

I've had the following article sitting as rough notes in a Google doc since at least 2017 or 2018. But despite being a few years old it hasn't really dated, as it represents some pretty fundamental thinking about the craft of software development.

So I decided to blow off the digital dust and do my best to put some pretty disparate thoughts into a more cohesive form.

Three common issues affecting software development teams

The following three issues are ones I have frequently run into during my career in software development. I don't claim by any means to have solved them. But I've thought about them a lot. I have seen what has worked in the past to overcome them, and more importantly what hasn't.

Difficult questions

Here are the issues expressed as questions. I would guess they are asked by most development teams at one time or another, especially as projects and teams scale upwards:

How do we...

1. Move much faster?
2. Estimate and measure progress at all levels of a project?
3. Identify bugs as early as possible?

I've come to realise that the issues that prompt these questions are interlinked...

...or in other words they all stem from one fundamental problem. These questions arise to the extent that we do not approach software development in an atomic fashion.

When we do not take small, measured steps in the way we produce software, things are slower, harder to estimate and measure, and prone to be buggy.

This ain't no silver bullet

I realise that there is nothing revelatory about identifying these issues, and there are plenty of great tools and methodologies out there to overcome them. Otherwise we'd never see decent software released, and we do.

So I'm not presumptuous enough to believe I'm able to offer up any particularly revolutionary solutions here.

Said Fred Brooks:

There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity.

Agreed. Yet there are almost always ways to substantially improve how we craft software both as individual developers and as collaborative teams. Complexity in software is inevitable, but wherever possible, let that complexity be essential rather then accidental. And especially, do not let unnecessary complexity be due to a lack of discipline and rigour within a team.

Outlining the issues

Before I go on to discuss the concept of atomic development, let me first outline each of these three issues in a little more detail.

1. Speed

Adding manpower to a late software project makes it later

My hand is raised. I've done this. And it did!

This quote is another by Fred Brooks and has been so often cited that it's come to be known As "Brooks's Law" and is the main theme of his 1975 book, "The Mythical Man-Month: Essays on Software Engineering".

A commonly perceived solution to the first of my three questions, "How do we move faster?" is to throw more people at the problem. Not moving fast enough with two developers? Let's add two more and move twice as fast. Brooks demonstrates the fallacy to this type of thinking. In brief: more developers = more communication overhead and at a certain point rather than increasing speed, adding people results in a decrease in speed.

On development speed more generally, it often seems incredible to me how rapidly a single, motivated developer with few constraints is able to work. At one point I was the sole front-end developer for a project in start-up mode and it felt as though I could churn out features in super quick time.

As we rapidly scaled, one front-end developer (me) became one novice development manager (me) and a talented team of half a dozen, and I found myself sometimes frustrated at how long things suddenly took and how much more complex everything seemed. There was now a whole class of problems that never existed before: huge merge conflicts, different coding styles, disagreements over approach, who would work on what, and so on.

We were a good team, but I often thought to myself "surely we ought to be able to move faster than this". It also leads me to believe that smaller teams are better teams.

2. Measuring progress

This quote, or variants of it, is often attributed (perhaps incorrectly) to Peter Drucker, the father of modern management thinking:

If you can't measure it, you can't improve it

In software development, observing and measuring progress can help to change and improve the process naturally, so long as a team is made up of people who are striving to become better at their craft.

Any form of measurement should enhance and improve the process. It should not impede or slow things down. Measurement should be an integral part of being productive, not a bolt-on or afterthought.

But it's hard to measure progress if you have no estimate to measure progress against. Which brings us to a problem:

Developers hate estimating

Software developers tend to strongly dislike being asked to estimate how long an assigned user story or project is likely to take.

Why?

• Because much is unknown at the outset and only becomes known as progress is made.
• Conscientious developers are eager to please (or too sure of themselves) and are often wildly optimistic.
• Morale is killed when the target is missed - which will happen most of the time!

But... businesses inevitably have deadlines. Customers have expectations. CEOs are answerable to their boards. As much as we might like to say that a project “will take as long as it will take”, for success, things have to be delivered more or less on time. Otherwise money invested does not make a return, budgets set are overrun, partnerships are damaged, and clients take their custom elsewhere.

Estimating is the biggest source of friction between a development team and product/project managers or other stakeholders in a business. This friction is needless and unhealthy. A product team and a development team should be highly collaborative and mutually supportive, rather than adversarial.

Some sobering facts

Only 29% of Software Projects are successful (defined as on-time, on-budget and with a satisfactory result)... Agile approaches showed a 39% ratio of successful projects, while Waterfall only 11%.

Agile is over 3× more productive than Waterfall. But 39% is hardly an 'A' grade.

Agile has tried some interesting approaches to estimating: Planning Poker, arbitrary units of “effort” instead of time, etc. But these are just trendier, fluffier forms of time-estimating and, deep down everyone knows it. Even with the no-time approaches, the tendency is to (at least privately) translate points to time or person-hours.

More recently, the #NoEstimates movement has come about. The problem with #NoEstimates is that it sounds scary to the business folk when you take the hashtag at face value. The term is somewhat counter-productive. On the surface it appears to encourage an attitude of “it will take as long as it takes” or at least "let's assume we never know how long it's going to take". To me that feels like giving up before you've even begun. Estimating is hard but that doesn't make it impossible or pointless.

For a business to be successful, the shoulder-shrug attitude can never work when it comes to estimating. It's not professional for a start, but also ignores that fact that simply by measuring progress, “it” will almost certainly take less time than it would otherwise take.

However, some of the ideas that accompany the #NoEstimates concept are very worthy, many of which are contained in my thoughts on Atomic Development which follow.

A previous team of mine used to hold long planning poker and effort-scoring sessions and eventually deemed them to be more harmful than helpful. The developers went on to practise a form of #NoEstimates which boiled down to holding a weekly planning meeting and a finger in the breeze feeling of whether this seems like “something I can get done within one sprint-week”.

That's all the developer had to be concerned about. "Can I commit to having this done by next week?" The project managers and development managers used a system of T-shirt sizing which was kept intentionally opaque to the development team and was used to communicate estimates upwards. This tended to be based on past precedent, estimating against previous projects of a perceived similar “size”.

This all sounds somewhat wishy-washy and is certainly far from perfect, but nonetheless had many advantages and was certainly preferable to planning poker.

However it does not encourage rigour and discipline, the lack of which can surface in worrying ways: reduced code quality, lack of testing, sloppiness and perhaps above all, no ability to properly measure true progress.

3. Identifying bugs early on

Having a release held up by the discovery of a last minute showstopper bug can be painful. Thankfully, modern continuous integration tooling as well as test-driven development have done a huge amount to reduce the need for manual QA and to identify bugs early.

Bugs fixed early use up less developer time. They are in parts of the code that are fresh in the mind. One bug can reveal a whole host of others, which becomes more likely the longer the bug exists. In review meetings the same longstanding unfixed bugs crop up again and again and eat up valuable discussion time. If a bug sits around it is likely to be reported multiple times, which again eats up somebody's time.

It is an impossibility to have completely bug-free code, but this does not excuse a development team from a diligent commitment to quality.

What is Atomic Development

Again, it's no silver bullet, but the term Atomic Development encapsulates what I feel is the most disciplined and robust approach to software development in a growing team.

The "atom"

In physics, an atom has two qualities that make it a useful metaphor on which to model the production of software:

1. An atom is the smallest particle of an element that can possibly exist
2. All the atoms of an element are the same size

In atomic development, a software "atom" is the smallest viable coding task that cannot be further broken down into smaller tasks.

By "viable", I mean that the task both starts AND ends with the software in a stable, production-ready state. This is important!

Software atoms are all roughly the same size, meaning each takes about the same time to produce. Software atoms are therefore easily measured. They are quantifiable.

In practice

For atomic development to work, a certain amount of discipline must be collaboratively and universally agreed upon and woven into the fabric and culture of the development team. But rather than a hindrance, this added discipline can prove to be extremely liberating. It reduces stress and pressure within in a team. It greatly improves morale, both in terms of a personal sense of achievement and as a wider team.

A sense of achievement and purpose is brought about by seeing things done. By shipping code. Little and often. The longer a task takes, the more momentum slows and the more disillusionment grows.

With a few basic rules applied, a software “atom” can act as a unit of measurement and unlike arbitrary effort points the atomic unit is based on something real. More on that later.

What about user stories?

The idea that small tasks are a good thing is not new. This is an inherent part of the Agile approach. But usually, it is the “user story” which is talked about as the smallest entity.

In Atomic Development, user stories still keep their place, but they are not the “atom”, the atom is much smaller. Think of the user story as more of a molecule. Project managers work at the molecular level, but developers work at the atomic level.

The advantage of a user story is that it encapsulates a feature (a beneficial change evident to a user) in terms of a product “deliverable” that is easily testable and definable. Agile development encourages user stories to be as small as possible. The thinking goes like this: start with a minimum viable feature, build it quickly, ship it, then iterate and improve upon the initial offering.

User stories resonate with project managers. They are a proven way of scoping, testing and accepting a new feature and as such are very valuable. For a project manager, the user story is usually the smallest unit they have to think about.

The drive to make things small is laudable, but that doesn't often work with user stories. Often, even in their smallest form they are still describing a feature that has a lot of complexity under the hood.

In addition, one user story is not usually the same size as the next. Certainly they do not take roughly equal times to develop. Each must be individually considered and estimated.

For example, this might be a typically-worded user story for a travel application:

“As a user looking to book a hotel, I want to be notified by email when the price of a hotel falls below its current price so that I can be sure I'm kept aware of the best rates.”

The technology to bring this one-sentence user story to fruition could represent weeks or months of work. This then, although seemingly simple on the surface, could be considered to be an “epic” or “macro” user story that could be subdivided into smaller stories. These might be concerned with the contents of the email notification, a call-to-action appearing next to a price, the form to sign up for an alert, the on-site merchandising of the feature, the process for gathering and analysing rates and so on. And each of these could then be potentially further subdivided.

Looking in the other direction, the price alerts user story might be one of a number of stories making up a larger effort aimed at retaining users and encouraging repeat visits.

Breaking down the user story

It can be hard to figure out how best to make user stories as small as possible. For example, imagine our user story for a form allowing a user to sign up for a price alert. The user interface consists of a set of form fields and a button to submit the form. Should the user story encapsulate the entire form? Should each field be a user story in its own right, should the button have its own user story? Should the functioning of the button and the styling of the button be split into different stories or part of the same one? What about the back-end code to process the submitted form? Etc, etc.

There is no real right or wrong answer to some of these questions. However at a certain point a project manager can be in danger of trying to do the developer's job by figuring out how to delineate tasks along technical lines. Then user stories can cease to be user stories at all and instead become a list of tasks or tickets. This is something that happened at my former company where we were creating things that were actually simply coding tasks but we were still calling them "user stories" despite them not being anything of the sort.

Here is where Atomic Development comes in.

For a project manager, the smallest unit they have to think about is the user story. Although the developer is aware of the user story and engaged with and committed to its successful realisation, they do not think in terms of user stories. The developer thinks instead in terms of coding tasks, that usually have to be completed synchronously, one after the other in order to bring a user story to life. The developer often has to translate a user story into specific steps that make technical sense. These are often kept in his/her head or scribbled down on paper, or as a checklist stored against the user story in a tracking application such as Jira, Pivotal Tracker, Trello or monday.com.

But most of these tracking tools only allow two or three levels of breakdown. You may have the three levels like this:

But as with user stories, development tasks can sometimes be divided into sub-tasks. And sometimes subdivided even further until you end up with at the so-called atomic level of tasks, a software “atom” being the smallest viable coding task that cannot be further broken down into smaller tasks, with the software remaining in a production-ready state once the task is complete.

AFAIK, none of the tools listed above allow this level of breakdown. This forces the expression of real-life work patterns to artificially fit the tooling, when it should be the tool that reflects reality.

Don't break things down too far though. Don't split the atom! Unless you want things to blow up! If a change to the code leaves the software in a broken or an untested state, then the task is not atomic. It remains undeliverable until the software is in a stable state, ideally with a full complement of tests to demonstrate that fact.

Defining an atom

An atom is a clearly defined step representing progress. A small step but a definite step.

Some rules to define a software atom:

• It must not break the build
• It must leave the software in a stable, production-ready i.e. shippable state.
• It must be small enough to be easily completed within one working day
• An atom ideally equates roughly to a single push or commit

This may produce some initial pushback from some developers. Some developers love to work in a silo and be left to their own devices working on a feature on a feature branch until it is finally ready after two days, a week, a month (who knows) to merge into the main branch. They may object that what they are working on is so complex that it's impossible to make small stepwise commits at least daily.

If this is the case then they are in almost all cases wrong and should be encouraged to think harder about the task at hand. However, developers should be allowed an exploration phase if necessary to answer any unknowns (more on this later).

As an atom often represents only a small step towards a larger user-story, short-lived feature flags can be used to “hide” in-progress features from users allowing the developer to safely ship code on an at-least daily basis.

It may seem more laborious to take lots of baby steps when a few huge strides might do, but there are some big, big advantages to ensuring an atom of software takes no longer than one day to develop and ship.

1. Measurability
2. Disciplined planning
3. Purposeful stand-up meetings
4. Improved code reviews
5. Bugs are more likely to be found early
6. No long lived branches
7. A continuous sense of individual and team accomplishment

Measurability

A project manager need not worry about how a developer breaks up their user story into atom-sized tasks, but they should insist that the developer always goes through this exercise. It should not matter at all to the PM what each task says or means. It is the developer's prerogative to break down the larger user-story any way he/she sees fit. The PM only needs to track the completion of each atom so that they can measure progress against their user stories.

A project manager can safely assume that each atom will take no longer than 1 day to complete. Therefore if a developer breaks a user story down into 5 atomic steps, a project manager knows that the larger user story (the thing they care about) should take a maximum of 5 days to complete. (Anything less is a bonus but it is also conceivable that atoms will be delivered ahead of schedule - and when do you ever hear that in the software business?)

An organisation may choose to quantify an atom differently than one developer-day. This is okay. There are no hard and fast rules here so long as the underlying principles apply. Remember that a developer's day is not just taken up by coding. There must be time for meetings, code review, emails, Slack conversations and so on. There may be some days where a developer is not able to write code at all. All this needs to be taken into account when coming up with the optimal size for a software atom. Some organisations may exclusively pair-program, in which case an atom would be two developer-days. But in general, one day seems like a good starting point in terms of being able to accomplish at least one step forward in code written, tested and delivered.

In a system of atomic software development, atoms, tasks, user stories, epics and large projects all make up a project hierarchy that can be viewed, and progress measured, by: stakeholders at the project level, developers at the atomic level and project managers at the user-story level. As many layers of hierarchy as needed should be allowed. And at each level it should be easy to measure progress. All progress is recorded by the developers at the lowest atomic level quite simply by marking atoms as delivered on at least a daily basis.

Whatever tooling the team chooses should allow the completion of atoms to be viewable as progress against the next level up in the project hierarchy and so on all the way up to the high level view, as in this very simplified view:

The project hierarchy must be flexible. Requirements can change, scope can increase, bugs can be unearthed as with any project. Any additions will create more user stories and more atoms which update the progress measurements accordingly. However, because the size of an atom is quantifiable, stakeholders have an immediate and accurate view of the impact of change requests as soon as the corresponding atoms have been defined.

The planning process to record each step required to deliver a user story replaces the older idea of estimating. As an atom should take no more than a day to complete and as a tiny task should be quite accurately estimated, it is feasible that many atoms might take far less than a day. This gives the estimates a built in conservatism where you start by looking at a very accurate worst case scenario that (hopefully) looks rosier over time.

Disciplined Planning

For an atomic development process to be successful, a high level of discipline is required from every developer in the way they plan their development tasks.

We are not creating abstract art, we are engineers. No good engineer begins without a highly detailed plan or blueprint of some kind.

Having been assigned a user story, and before writing the first line of code, the developer must attempt to map out a series of tasks broken down as far as possible into atom-sized steps. These take the software from A (current state) to B (completed user story). Each step must be production-ready, well-tested and safe to be deployed.

If your team practises Test Driven Development, then planning out atomic steps works particularly well. Each step can be expressed as a test, which is written first, code second.

This does mean that the time spent planning as a team and personally may be greatly increased from what developers are used to. But it's a valuable and worthwhile discipline. Planning early saves a lot of wasted time further down the line. Problems are anticipated and thought through earlier.

This might initially result in some expressed concern from developers. “How can I know what the steps from A to B are until I start digging into code and working out how to do this?” It's a valid question and the answer is that sometimes you can't know the correct path until you walk it and discover some of the pitfalls along the way.

Sometimes a new feature may require a large refactor of existing code to protect against a build-up of too much technical debt as new code is introduced. Refactoring can be particularly hard to estimate as you are trying to unravel another person's code and the extent of what is involved is often not apparent until you've finished unravelling.

In this scenario it is still possible to produce a set of atomic steps before beginning to write code. But, in order to figure out what the steps are to get from A to B and to map out the software atoms required, some experimentation may be needed first.

The Mikado Method

A working method known as the Mikado Method is a structured way to make significant changes to complex code. Its basic premise is this:

1. First, explore and experiment
   • Create a temporary branch in Git.
   • Figure out what the steps are to get from A to B by hacking, prototyping, refactoring etc.
   • Record the steps required to achieve success (each step will become an Atom).
   • This effort should only be considered a prototype or disposable draft
2. Then, throw away your branch, (or if you keep it around use it only for reference). Now you have your plan and your estimate expressed as a sequence of Atoms.
3. Finally, write the code for real, one atomic step at a time.

If a developer is unsure of the steps needed to complete a user story, project managers should afford them adequate time to experiment as described. But there should be a window of time granted, even if it is a generous one. One Sprint, for example.

It will require skill on the part of a project manager to buffer the project estimates to include adequate time for the planning process and any experimentation required.

No Massive Re-writes

Atomic Development also naturally encourages teams NOT to embark upon huge rewrites of software. It lends itself instead to safe, stepwise evolution of software (and systems) from their current state to a future, improved state.

Again, when the instinct is to throw away the old and completely rewrite, the wise and disciplined developer is much more likely to figure out a way to evolve the codebase instead. And again, if this feels like an impossibility, that's almost always untrue. It just takes more thought. Use the Mikado Method. Figure it out for real.

I'll spare you the painful details, but having been bitten hard in the past by my own decisions to rewrite perfectly adequate codebases, I don't think I would ever willingly embark upon a rewrite again. It's those painful experiences that have led me to become such a proponent of Atomic Development.

Purposeful Stand-up Meetings

With atomic development it is easier for a project manager to quickly tell if a developer is falling behind as each atom constitutes no more than a day's work. If an atom takes more than a day to complete then perhaps there's a problem to be flagged: a blocker for example, or more complexity than expected. Perhaps the atom is not an atom and needs to be broken down further.

Daily stand-up meetings automatically become much more purposeful as PMs can find out what might be blocking progress and how other team members can help out. Crucially, a reduction in velocity becomes obvious within the space of a day rather than a week or more.

When developers are working at the user-story level, their stand-up meeting contributions may not be very useful and can often become habitual and repetitive, something like: “Yesterday: Working on the sign-up form, Today: More on the sign-up form. No blockers”. It's easy to imagine a week or more of identical, and pretty useless, status reports.

With atomic development, things are more fine-grained. This means that each day a developer's stand-up report should be different from the previous day, because they'll have completed and delivered at least one atom during that day. Reporting on that completed atom gives a more informative and accurate view of sprint progress for the rest of the team as well as placing more accountability on the developer to be sure that each passing day brings evidence of progress.

Stand-up meetings also become the daily interface between developers and project managers. The PMs running the meeting are speaking the language of user-stories. The developers are reporting progress towards those user stories in terms of atoms and any potential blockers surface very quickly.

Improved code reviews

If reviewing code was easier, it would likely happen more often.

If a code review took less time, the effectiveness of the review would be likely to improve.

Software atoms should, by design, be small and very easily digestible. Think a single function or a few lines of code. This means code reviews are much more likely to bear fruit as there's not a lot to consider. Having to code-review an entire feature spanning multiple files and consisting of hundreds of lines of code is a daunting task, not at all enjoyable, and likely to be undertaken half-heartedly. Code review then is in danger of becoming a box-checking activity rather than a tool to ensure software quality and improve the skills of the team through constructive feedback.

Here are a couple of common approaches that a team could consider for pushing their code to the shared repository in order to make it available for review. These are only suggestions. This process can be whatever the team is most comfortable with so long as it lends itself to getting code into the main branch as quickly as possible, with few or no hold-ups.

Trunk-based development

Developers all push to the main branch and rebase to their local repository. All commits to main enter a deployment pipeline and, so long as all CI steps pass muster, automatically make their way to production. This incorporates an obvious degree of risk and so requires an excellent automated test suite and a team of disciplined senior developers.

Developers must be able to keep a continual eye on commits other developers are making and know where everyone else is working to anticipate potential conflicts. A system is put in place where one or more developers reviews all the commits hitting the main branch immediately. This could be a “repository owner” who has permanent responsibility for reviewing the code that hits his/her repo. Or a developer could take on code review responsibilities for a day or week. Or the team could do bi-weekly or weekly code reviews of each commit. Or a proper system of pair-programming could ensure peer review of all commits before they are even pushed.

High review standards must apply, particularly an expectation for adequate test coverage as part of the delivered atom.

Use Github pull requests

Developers push the committed atom to a short-lived remote branch and create a pull request from that branch. The branch cannot be merged into main until another developer has reviewed the code. Developers can comment on the code as needed or even make proposed tweaks directly to the code they are reviewing. Github has tools to invite other developers to perform a review. Either a PM or the author of the code should be responsible for ensuring the code is reviewed in a timely fashion, with freedom to nag the rest of the team in-person or via a tool like Slack.

This method may be preferable in a team with more junior developers where there need to be more safeguards vs trunk-based development.

The danger is that while awaiting code review, subsequent atoms continue to be pushed to the same branch and will add to the size of the pull request which is no longer atomic. This leads to branches that live longer than is safe and presents more overhead for the reviewer.

Once the pull request is approved, the author should ensure the latest changes to main are merged in (resolving conflicts if needed). This can usually be done within the Github interface with a single button click.

Once the pull request is up to date with the main branch it can be safely deployed to production. This deploy could happen 1) from the branch itself, assuming it has undergone a CI process before a deploy is permitted. 2) or it could be merged to main which begins the CI and deployment process.

The code-review branch can be discarded as soon as it has been merged to the main branch.

Find bugs early

Early identification of bugs is key to healthy software. Frequent code review of small pieces of code means bugs and other issues are much more likely to be spotted very early in the deployment process.

Planning how to break down a user story into atoms, forces a developer to think carefully about their work and allows them to anticipate problems in advance. If a developer jumps in and just starts building without planning each step or atom, it's like building a Lego model without having taken the time to come up with a set of instructions first. It is poor engineering (aka cowboy-coding) to work without a clear plan on how to get from A to B. Serious bugs and a poor quality product are likely to be the result.

No long-lived branches

Code branches in Git are a useful tool but the longer code diverges from what is in the main branch, the more likely it will be problematic to merge the new code in at the end of the development process. This can cause very complex merges with numerous conflicts to resolve, again making the likelihood of bugs being introduced very high.

Pushing atomic pieces of code on a daily basis makes the likelihood of long-lived branches very unlikely.

A sense of accomplishment

Measuring success is just as beneficial for an individual software developer as it is for a project manager or a Business Stakeholder. The developer gets to feel a real sense of progress as each atom is marked complete and is also able to see how his/her efforts are benefiting the progress of the team's wider efforts. Completing small atomic tasks at least daily creates and maintains momentum and makes it less likely that a developer will be distracted or sidetracked.

If a developer is not considering work to be completed until a 3 week long user story is marked as delivered then the opposite is true and it can cause momentum to slow or a false feeling that the developer has more time to play with than they actually do.

Conclusion... and a word about Agile

I tend to shy away from too much process, too many rules and highly opinionated systems. I favour the "people over process" principle of the Agile methodology. My cheerleading for Atomic Development does not stem from a love of process. Indeed, I don't believe Atomic Development to be a process but a mindset that ultimately proves liberating for development teams.

It's really all about a shift towards more meticulous thought and planning. Diving into code is often an eager developer's first (and laudable) instinct. Everyone wants to feel productive and after all, writing actual code feels productive. Planning sometimes not so much.

However the discipline required to break down your planned code journey into the smallest possible steps is much more productive in the long-term as I hope I've shown in this article. Lots and lots of small steps, each step being a safe one.

This seems perhaps the antithesis to the Agile concept of a sprint. The term "Sprint" suggests speed. How can you be expected to sprint at speed when taking small steps?

I want to state very strongly that Atomic development is not at all in conflict with the principles of the Agile Manifesto.

Agile promotes delivering working software frequently. So does Atomic Development. Every atom is a working change. Every commit is a delivery. Yes a very small delivery but Atomic Development is a method of "sustainable development", with a constantly maintainable pace. Exactly what Agile puts forth. Ultimately it helps you go much faster. It's the disciplined tortoise vs the undisciplined hare.

There will always be unknowns and that is fine. Unknowns are the interesting and exciting part of producing software. But these unknowns are discoverable and do not excuse long periods of coding in a silo to discover and resolve them. The trick is to make the unknowns known as early as possible. Atomic Development, especially the Mikado Method helps this to happen.

Agile does not mean thoughtless or slapdash. A minimal viable product must actually be viable. Too often the essential viable attribute is neglected in favour of the minimal part. Atomic Development keeps projects viable by making sure they are measurable and of consistently high quality. And... I truly believe that Atomic Development saves a great deal of otherwise wasted time that might not be apparent in the moment but only in retrospect.

Again, it is no silver bullet, but the more people you have working on a codebase, the more valuable the concept of Atomic Development becomes. So yes, although in essence it is just the principle of "commit little, commit often", it can be quite a challenge to institute a team culture that fully espouses it. But if you can, it ultimately leads to a happy, communicative and productive team.

Further Reading

Articles I gratuitously and shamelessly stole ideas from:

Why Asking Software Developers for Time Estimates Is a Terrible Idea and How to Bypass It

Forbes: You are What You Measure

Harvard Business Review: Why Your IT Project May Be Riskier Than You Think

Doing Scrum without Estimates

What is the Mikado Method?

Trunk-based development

Get in Touch

If you have comments or thoughts of any kind about this article, I'd like to hear from you. Send me a tweet @tomsouthall.