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.
Test-Driven Development has gone from being a new idea, considered slightly crazy, to a serious development style used by many professional developers in their everyday life. However, it is a style of development which requires much discipline, or you will not realize it’s potential. In fact, you might end up doing more harm than good.
Sometimes when I’m trying to get my head around something complex, I suddenly feel overwhelmed and my head starts to feel like its about to explode. I realize that there are at least a dozen cases which I’ve failed to consider so far. All the thoughts I was trying to keep track of just runs off in every possible direction and I can’t chase them all. Dispair overwhelmes me. Then I have to close my eyes, take a deep breath, hold it for a second, and let it go slowly. Then start over, think it through one more time.