Browse files

Test commit

  • Loading branch information...
1 parent 9512279 commit afc18fea336eb6f85d38feac08e9dad945c274b1 @timonv committed Apr 23, 2012
Showing with 111 additions and 0 deletions.
  1. +1 −0 _config.yml
  2. +110 −0 _posts/
1 _config.yml
@@ -1,6 +1,7 @@
# This is the default format.
# For more see:
permalink: /:categories/:year/:month/:day/:title
+markdown: rdiscount
exclude: [".rvmrc", ".rbenv-version", "", "Rakefile", ""]
auto: true
110 _posts/
@@ -0,0 +1,110 @@
+layout: post
+title: "Programming Amish"
+description: "Using simple solutions for complex processes"
+category: "agile"
+tags: [agile, management]
+{% include JB/setup %}
+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, <strong>they are only
+distractions not needed for their way of life</strong>. Their way of
+life doesn't have any problems that any of these would solve. Isn't that
+<strong>amazing</strong>? 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 bi annual gathering. Development in
+<strong>any</strong> environment should be <strong>fun</strong>, I hope
+this guide helps to achieve just that.
+You can find the accompanying slides <a
+<h2>What is software development about?</h2>
+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
+<h2>What goes wrong in software development</h2>
+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.
+<blockquote><strong>“Simplicity is the ultimate sophistication.”
+</strong>Leonardo da Vinci (Italian draftsman, Painter, Sculptor,
+Architect and Engineer whose genius epitomized the Renaissance humanist
+ideal. 1452-1519)</blockquote>
+<h2>What is simplicity</h2>
+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
+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.
+<em>In response to the discussions afthis, only you can. </em>

0 comments on commit afc18fe

Please sign in to comment.