Rereading “Implementing Lean Software Development”

After some time I reread Mary and Tom Poppendieck’s book and came to a paragraph that had previously not caught my attention (or I forgot that it had). In my defence it was in a passage about Google (which is not of particular interest to me) underneath a prominent insert, but nonetheless, it struck a nerve with me now, since there are lots of discussion about the Death of Agile for quite a while now:

“This is also the time [feasibility phase] for systems design, a critically important discipline that many companies seem to do without. […] It should neither be done by an amateur nor by arms-length experts. Rather it should be done by seasoned designers who know the systems design will evolve as the product emerges and who know how to make sure that evolution is taken into account so it can proceed smoothly.” (p.47)

So, there you go, one of the major pitfalls. From my own sad experience I can say that system design is the barren wasteland in most companies building software products. They do Scrum, Waterfall, Unified Process, Kanban, XP, Lean, you name it, but on the systems design level decision are still often made with arguments like:

  • [Big company] is using it and they have millions of users, so if it’s good enough for them…
  • Everybody knows that X is the best for Y.
  • You know X is really an expert in [programming language, tool, technique] so we take it.
  • Our old software was running for a long time with X, we should stick with it.
  • X is really around for a long time. At least we would know all the problems and could google them.

I’m sure everybody knows meetings where arguments like this come up (and many more equally sad ones). Normally not from the development team, but the management. But why?
Building a new product is a risky business, you can fail. This is scary. And scared people try to get safety wherever possible, thus forcing a technical solution onto the developers because they can’t give you a guarantee for the projects success and let’s be honest when did the technical gibberish of developers ever beat the argument that f***book or whoever is using it? So the development is left with screws and a hammer and tries bravely to use the impact of the hammer to make the screw rotate, because some other big company is using nails and hammers.

But what to do about this screwed up situation (pun fully intended)?

If you don’t have a seasoned designer on your team it is easy: Hire one, get a consultant, research, discuss
If you have one: Let her/him do his job and don’t try to get guarantees, there are none.

So my feeble take on systems design:

  1. Avoid big enterprise frameworks (unless you are big, as in massive).
  2. Microframeworks are more likely to be able to allow changes due to their pluggable nature.
  3. Define the platform you want to run the software on early and keep deployment in mind.
  4. Plan without css/js frameworks and add them if they provide a significant benefit.
  5. Enforce coding styles and guidelines early on. Otherwise changes and debugging will be a death by a thousand papercuts.
  6. Encourage learning and teamwork to improve code quality and knowledge of the system.
  7. Try your best to keep employees to avoid knowledge drain.
  8. Estimates are not deadlines! Cutting corners to keep a deadline that was an estimate will cost you dearly later.
  9. Automate early!

Git Hook, Line and Sinker

Selfhosting your git repositories is not a bad idea. In fact it is a great idea and it’s pretty simple too.

First you make a new directory on an accessible machine which by convention ends on .git. Something like /allmycode/repo1.git

Move into the directory and execute

 git init --bare --share

Great, we got ourselves a shareable git repository. If you dont’ want ro be the only one to be working on that repository and have no intention of making it public either you should create a user specific for git operations on the machine you serve your repositories from.
Let’s assume your specialized user is called “git”

You can now add ssh-public-keys from all parties that should have access on the repos via copy-ssh-id to /home/git/.ssh/ and have a nice passwordless access-control.

Now we can start to work on the remote repository.
In you local working directory we

git init

and provide the user information that is used in the commit message

git config --global "Your Name"

git config --gloabl your@email.sth

This was all local, so let’s add the information about remote

git remote add origin git@server:/allmycode/repo1.git

this enables us to make a push to remote with the shorter

git push origin master

It is completely viable to add differently labeled remote repositories e.g.

 git remote add github sth@github

and push a specialised branch (without passwords for example) there via

 git push github public

Nice, self-hosted remote repositories! You can start collaborating. And when you do you, you might want to automate transferring the newest version to a testing server. You could do this with a cronjob and some copying, or, you could use git’s very own hooks, to be specific a post-push hook.
Connect to the remote repository and enter the directory hooks/. Here you find some nice samples, but we want something different. We want a post-receive hook, which means everytime somebody pushes changes to
the remote repository this action is called. So we create that hook:

touch post-receive

then we paste in

GIT_WORK_TREE=/path/to/serverroot/ git checkout -f

and save. Make it executable and you made a git hook. Congrats!
Since we have a user named git who is the owner of all the repos on our remote machine we must add him to the group that controls the webserver paths (www-data or else) Full instructions to make the checkout work.

Now every push to the remote repository should trigger a checkout which hopefully makes the newest version available on the webserver.

But let’s tweak things a little. Say we want to be notified whenever a commit has been pushed. Email and telephone are viable but timeconsuming and you don’t want to, and frankly should not have to, bother. I think Jabber is a great way of getting the information across without spamming the whole team. So I made a little script to send a message to everybody who cares to give me his jabber-id. You can get it here via

git clone

If you add to the post-receive hook

 python /<path-to-repo>/ "Something has been pushed."

not only will your testing/demo/development server automatically have been updated, but all listed members of the working group will be informed about it on Jabber.