Reading Richard Dawkins’ book The Greatest Show on Earth, I got inspired by his description about genes. He talks about how genes are not the blueprints of the body, but rather a recipe for the body. In other words, the genes do not contain a complete (or even partial) description of the final result, but [...]
In a conversation with Michael Feathers at SDC2010, he mentioned something which I found very interesting. It was a very simple statement.
Constraints are good.
To me, that statement sounded rather odd. Constraints is a negative word to me, so intuitively I want to remove constraints. Thus, I asked him to clarify. And here’s what [...]
An time estimation rule of thumb for software development in startups. (Somewhat tongue-in-cheek.)
The rule
Make a good estimate of the work (in any time unit). Multiply that number by itself in months plus one. What you get is a reasonable estimate for release date (in the original time unit).
Examples
Some examples:
Work estimated to one week will take one week. Work [...]
The Bus Factor, as defined by Wikipedia:
A software project’s bus factor is a measurement of concentration of information in a single person, or very few people. The bus factor is the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray [...]
This is a bit of a rant, but I just gotta get it out of my system.
I’m getting frustrated by people I talk to who seem to misunderstand the whole point of agile software development (IMHO).
Different ways of reducing risk
The point with agile, as far as I understand, is to reduce risk and thereby costs [...]
A buzz word within the Agile camp is ”cross-functional teams”. For some reason though, there seems to be quite some confusion about what it really means. More precisely, it seems that some people argue for that members of a cross-functional teams should be generalists rather than specialists, that everyone should be able to do every [...]
I’m really starting to get annoyed by people who insist on comparing creating software to building a car, and software development to an assembly line. That might have worked more or less fine with old, long forgotten(?), waterfall processes. But wake up, we don’t do software that way any more — most of us anyway.
The [...]
This time, I’ll just provide a short note of insight regarding checking code into version control.
If a commit message feels very long, or you feel a resistance against writing it because you don’t know what to write, it has probably been too long since you last committed! If you commit after each task is done, [...]
In the nineties, software development was conceptually simple and straight-forward; you gathered requirements for the system, designed it, built it, tested it and deployed it. This was the era of waterfall, RUP, UML, and lots of up-front design. The more details decided in advance, the less costs from changing later, and thus, the better.
Then, somewhere [...]
In the last few years, especially in the agile corners of the web, there’s been quite a lot written about the 40 hour workweek, sustainable pace, no overtime, and so on. I agree with most of this stuff and think exhausted developers in the long run do more harm than good. I can’t help to wonder, however, what’s so magical about 40 the hour workweek? Why not 35, 45, or even 55? Just playing safe on 40 seems a waste, if my team can do better.