Programming Amish
The Amish are a people who, besides their basic and very traditional way of life, have a firm grasp on the principles of simplicity. They do not have cell phones, computers, television or internet. Not because their religion dictates so nor because they aren't smart enough to use it. They don't use these things because for them, they are only distractions not needed for their way of life. Their way of life doesn't have any problems that any of these would solve. Isn't that amazing? Their value on simple, bare things is truly an interesting feat. Let's put that feat to use.
In this article I want to show you what simplicity in a development environment means. We'll recap on what the intent is of software development, a one liner on agile and see how simplicity works for developers and none developers alike. This article came forth out of the talk I gave at the Projectlodge.org bi annual gathering. Development in any environment should be fun, I hope this guide helps to achieve just that.
You can find the accompanying slides here.
What is software development about?
So, back to software development. Let's quickly recap what software development is about. Of course, every geek has their own definition of joy in writing code and solving related problems. However, for every businesses its usually the same thing: Adding value to the business. Or in more computable terms: Generating business value. Fixing bugs, maintenance and moving code around does not add business value, but its definitely necessary and can improve business value in the future. So, simply put the efficiency of a programmer (or team) is measurable by business value added over time. We'll get back to this later. In any case, whatever you define business wise, development should be fun.
What goes wrong in software development
The problem with software development I think is this; due to the inherent complexity of development, and the human tendency to fight fire with fire, complex problems get complex solutions. That usually implies that we get a rigid overhaul of how we work; but we can't really assert that our problem has been solved. 'Agile' for developers and 'Lean' for business try to address this. Both mention working from constraints as a start. That's nice and all, but how can I know that my solution fixes that one constraint, has no negative side effects andue changes, basically everything does, so pivoting quickly is the savior. The key to agile is simple; by acknowledging change is inevitable, we improve our work iteratively. That's it, nothing more. There's no need for fancy systematics or hot processes. These come later. Shit is about programming, and doing it right. Any complexity added to this process should be a simple, fundamental solution to any constraint or bottleneck on this process. Always try to improve, that is agile.
“Simplicity is the ultimate sophistication.” Leonardo da Vinci (Italian draftsman, Painter, Sculptor, Architect and Engineer whose genius epitomized the Renaissance humanist ideal. 1452-1519)
What is simplicity
Simplicity is the beauty of expressing in its most fundamental form. Its the art of reducing till only the mandatory fundamentals are left and all needs are still met.
When we're talking about processes, we are not necessarily talking about the bare essentials. We're talking about picking the constraint that limits generated value the most and solving just that.
If you have no process or you can't really name or define your process and you aren't delivering great software. Introduce one. Pick the essentials from one that works for you. Keep it simple, keep it bare and keep it clean. For instance, you could start with doing two week long iterations. Plan user stories per iteration and review each week what has been done, how everyone liked it and what has to be done the next iteration. It doesn't get much more bare than that. Side note; daily stand ups really help too. Its a social thing.
Then, start to take a look at what problems you, your team and your fellow team members have. Code Quality low? Take a look at code reviews. Lots of time lost with fixing bugs? Try automating your tests or even gasp Test Driven Development. Deployment taking days or even weeks? Hell yeah, go for continuous delivery. Team stressed out? Hit a bar! Developers stressed out from frustrating bugs? Try pair programming. There's a lot more of these solutions, and many aren't even tech related.
Metrics are another thing. Track how many stories are delivered per iteration and their value. There is nothing more satisfying than seeing and increase in productivity after a change. Tracking user activity and usage can act as a great motivator too. Whatever you track -- try everything -- don't forget that the map is not the territory.
Every iteration, review if the fixes actually worked. Convinced it works? Dump it for the time being, it might just not work for you. Or try a little longer and see how it fares on the long run. And for all these things, once they're implemented they're not done. Even they can be improved till sheer awesomeness. For instance, ywhat we've learned. We should look at the biggest bottleneck down the development pipe and fix those, one by one. Pick simple, small solutions and review. Track and measure everything and use those as both indicators of bottlenecks and motivators. Sure, great people mean a lot to the success of a project, but if they aren't delivering the right value, it's not going to happen. Tweaking your process allows you to introduce a lot of fun and productivity into development.
