Maintaining focus can be hard when developing software. There are a bunch of things that has the ability to steal our attention during a day. Mail, meetings, other projects etc. Over the last months we have found that keeping things simple, and not waste time on stuff that we believe don’t give us any value. So we have the following principle:
“Don’t introduce things you don’t need”
From a technical perspective we always try to keep things as simple as possible. We therefore have:
- No branches
- No un-necessary libraries
We also try to delay architectural decisions, keeping options open as long as possible. But more on that in a later post. Lets get back to avoiding branches and libraries.
If you are doing continous delivery, having no branches is a key element. But sometimes this is easier said than done. At one point we were about to introduce a more complex branching strategy. The reason ? We had a couple of incidents where defects were introduced in production, we released code that weren’t ready for production. So we gathered around our desks and started to discuss a branching strategy. As the discussion progressed we started to get a bad feeling. Things were starting to get complex. The concern was raised, and since we all really prefer to keep things as simple as possible we decided to look deeper. Was the no branching strategy really the problem ? Looking at how the work flows it became evident that the problem was that we didn’t really follow our own process (our Kanban board had a separate testing phase, where all our features need to pass an acceptance test). So instead of complex branching strategy, we agreed that we needed to improve our own testing:.
No unnecessary libraries
From the beginning the team has really done it’s best to keep our architecture and code as simple as possible. Whenever someone wants to bring a library, one of us put the “sceptic hat” on and asks: “Do we really need this?”. As a consequence, our code is still quite simple with reasonable few external dependencies. This makes our software easier to maintain and we can move faster when writing new features. The same goes for architecture (more on that later).
But it’s not only from a technical perspective we have valued simplicity. From the very start we have tried to create as little process as necessary, letting the process grow as we learned. The focus for the team should be to write working software that solves a business needs. Everything else should help the team accomplishing that. If it doesn’t provide any value, we simply don’t do it. Thus, we have:
- No (un-necessary) meetings
- No emails
- No estimates
- No testers
More details about keeping your processes simple in later posts.