I have realized that some people are smarter than I am. It is a painful realization but I just can’t ignore the evidence any longer. Allow me to explain. I often get inspiration to write posts from reading books or blogs by really smart people. Thus, I often refer to people who are smarter than [...]
In his great book User Stories Applied, Mike Cohn suggests that “the goal is for the estimators to converge on a single estimate.” While discussing this with a senior product owner at a major Swedish telco (guess which one!), I came to realize that there might be a point in not converging on a single [...]
Reading Lean Software Development, I stumbled upon the following quote. As a keynote speaker at a software conference, Enrico Zaninotto, an Italian economist, pointed out that the underlying economic mechanism for controlling complexity in just-in-time systems is minimizing irreversible actions. The notion of “minimizing irreversible actions” strikes me as a better way of capturing that [...]
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. [...]
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 [...]
My apartment is not always in perfect condition, and cleaning up that mess isn’t exactly what I look forward to. Therefore, in a discussion with a friend about this subject, I complained about that I couldn’t come up with good rules for myself on how and when to clean. (I like rules — simple, consistent, [...]
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, [...]
When using Struts 1.3 with Tiles and SSLEXT plug-ins, the application server throws an exception while trying to process a request telling you that the specified request processor isn’t compatible with Tiles. Here’s the solution.
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.
Sometimes we come to situation where we need to perform a major change in our code base, one that is likely to affect more or less the whole system and that would require many man-weeks to complete. Time that we typically do not have in the condensed schedule of a modern software development project. By performing the improvement step by step, at each commit, we can amortize the time spent over the course of the project, yet ensure that it performed.