They also created a new pedestrian crossing next to the tram stop. And there was one thing about it that I noticed. One side of the crossing was connected to the tram stop and the curb there was just rebuilt. The other side of the street had a perfectly fine curb, and it would have been no problems to just paint lines on the street and be done with the crossing. But they didn’t.

Instead, they ripped up the street, curb and part of the sidewalk on that side too. Why? The reason is that they wanted to improve that side of the crossing too. They’re making the sidewalk about half a meter wider and thereby narrowing the street. That makes it a little bit clearer that it is a crossing and therefore makes the crossing safer. They’ll lower the curb for a meter or so which makes crossing by bike or wheel-chair easier. That’s about it, as far as I know.

While arguably better, it didn’t really enable anything that wasn’t possible before. And it did cost money. Money that could have been spent elsewhere. And they had already spent a lot of money on rebuilding the tram stop. So why did they do it? I’m not sure, but I think whatever the reasons were, the same reasons could be used to motivate refactoring of software.

(Alright, that was possibly a crappy metaphor… but it’s my blog, and I’ll post what I want. )

You can finally get number of how much that “technical debt” really is. How much an average bug cost? How long does it on average take until a bug is discovered? Until it is fixed? How much did that quick and dirty patch a year ago really cost? Add to that all the technical value you could get out of such an analysis. What modules/classes have had the most bugs, historically? What classes are unstable and has to be changed all the time?

Think of it as a Freakonomics of version control.

Multitasking doesn’t work,
but it would be so nice if it did
that we try anyway.

That’s about the best summary of (human) multitasking I’ve heard.

This picture is pretty good too, though.

“With great power comes great responsibility”

So, if you can’t do it all yourself, you’re forced to either:

1. generalize and set broad rules, or
2. delegate control and responsibility.

The first one is tempting, as you can control people and ensure that they don’t do anything which they should not. The problem is, if you do this, you lower the “consciousness” of yourself and your organization. According to the Dreyfus model of skill acquisition, not taking context into consideration is one of the traits of the novice. And that is just what’s happening here.

On the other hand, if you delegate control to the people who actually deal with the everyday problems, each person can adjust their decisions to the situation at hand. If you don’t trust the people to handle that situation, either learn to trust them or don’t hire them in the first place!

I very much liked the idea, that a set of very low level instructions, carefully chosen and carefully followed, could create something so complex and beautiful. Jurgen Appelo has expressed similar ideas regarding complexity theory, and how ant hills or bee hives are complex structures created without a master plan through individual bees’ actions. Yet another connection would be local search algorithms, which find maxima in a landscape through looking only at their immediate surroundings.

Next, my brain started linking these ideas to software development. For example, Test-Driven Development. It is in its essence, a set of very simple rules. Write a test, write needed implementation, refactor. These three simple (at least in theory) steps is all that there is to it, when properly adhered to, it can give great results. Designs tend to be much more easy to use, contain less bloat, be more testable (duh!), and so on. Refactorings are another great example. A set of rules or recipes for how to transform a code base into a better code base.

Obviously, choosing the right set of rules to follow is the important part, as a bad set of rules will lead to crappy code just as an unwanted mutation in a human body may lead to e.g. cancer. But I guess the point I was trying to make is that there is immense power in follow simple rules.

My lunch mates felt that the decision to go with this vendor was not necessarily in the best interest of their company and the technical platform they were developing. Instead, they felt that there were other ways forward which would be better. Some of these ideas included common-sense things such as choosing quality over quantity, working on getting the current code into decent shape, and so on. They also felt that they had been trying to get this message across to management.

Why then did these suggestions not catch on with management, and why did the vendor’s salesmen manage to convince company management to choose them? I don’t have the answers, but I will not let that stop me from sharing my thoughts. I also don’t have all the details on this specific case, so I’ll be a bit more general.

I think that developers and architects have many good ideas on how to build systems, but that we don’t always do a great job of describing these ideas to business people. I think we also sometimes adopt ideas on the basis of liking them, rather than because the idea has been proven over and over again.

Failing that, we need to get a very well-paid management consultant to tell them the same thing. Because in the world of business, the greatness of an idea is proportional to the hourly rate of the person presenting it.

Some people who use test-driven development, also use tools that allow the to peek into classes and read private variables. That is an efficient way to ensure that some method altered the state of the object in the expected way.

However, as Michael pointed out, by doing so they miss the point of test-driven development. Test-driven development adds constraints. It does that in order to force developers to design their code better. (TDD is about design, not testing — remember?) By peeking into classes, one effectively removes one constraint added by TDD, and thereby removing much of the benefit of TDD.

Wow. That a blog post in itself—and a great warning to all us who are tempted to “go pro.”

So, consider yourselves warned, everyone. (Now, that would have worked way better if I actually had a lot of subscribers…)

His post made me think of how many bloggers that become popular behave. At first, they write good high-quality material, the kind of material that people want to read, and they get a lot of subscribers. As they become famous, they start doing talking engagements, they write books, they quit their jobs and starts making a livings as bloggers. And before you know it, most of what they post are “spam” such as info about their upcoming talk, book or business deal. And the posts which made me interested in the first place become rarer.

Now, that is only logical. They wrote about the subject in the first place because they were interested and worked with it everyday. When their life situation changes, and they become pro-bloggers, naturally their interests and day-to-day activities change as well (to some degree, at least). So they still write about what they are interested in and work with everyday. Same, same, but different.

Another commenter mentioned that he only followed people on Twitter with a moderate amount of followers and not the ones with millions, because the latter typically just sent broadcast-style marketing messages. Maybe that’s an expression of the same thing?

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 he said (or rather, my interpretation of it).

A big advantage of software development is that we can build virtually anything. However, that same fact also represents one of the biggest problems. “Anything” includes all the great things that we envision, but also all the crappy things which we typically produce.

Since the possibilities are endless, in theory nothing prevents us from creating something truly great. But — and here’s the thing — by adding wisely chosen constraints, we can eliminate some of the undesirable outcomes. That means, that even if we screw up a bit, we’re more likely to create something which is at least not half-bad because we’ve eliminated the really bad outcomes. If we stay within the constraints, that is…

Another way to see it is that just as any society needs some laws and rules in order to function smoothly, a software development team does too. Whereas an example in the first case may be “do not kill”, an example in the second could be “do not commit code which breaks the build”.

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 estimated to two weeks you can expect to be ready in close to a month.
• Work expected to take two months weeks will take about six months.
• Anything estimated to half a year or more won’t be finished. The scope will be changed too much before the project is finished.

While not perfectly scientific, it is actually more or less empirically derived from my own company’s history.

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 that it would not be able to proceed.

How would your company do without you if you became sick for a month? Six months? Quit completely? Or put the other way, if you want to quit, can you get out without leaving a complete mess behind you?

If you’re an entrepreneur, this is even more important. Especially if you’re looking into one day selling your company. Nobody wants to buy a company which is worthless without the seller.

What is the bus factor on your project or company?

A summary of the series:

1. Throwing Exceptions
2. Using Assertions
3. Catching Exceptions
4. Logging Exceptions (this one)

General guidelines

We’ll start off with a few general guidelines for logging.

Always include the exception message in the log

Never lose a stack trace!

Debug levels

A summary of the typical severity levels used when logging and guidelines on when to use them.

Info, Debug, or Trace

Warnings

Errors

Fatal errors

I hope this quick four part series on sensible exception handling has been interesting. Be sure to read the previous installments (see summary at top) and please feel free to add your comments below! Any and all comments are very welcome!

To quickly summarize, the series looks as follows:

1. Throwing Exceptions
2. Using Assertions
3. Catching Exceptions (this one)
4. Logging Exceptions

The information in this post is divided into two parts: when to catch, and how to catch.

When to catch

Here are some guidelines on when to catch exceptions and when to let them propagate up through the call stack.

Catch only exceptions you know how to handle, and be specific

Provide a general catch-all

How to catch

When you catch an exception, make sure to do it the right way.

Do not suppress or ignore exceptions

Always clean up after yourself

Declarative exception handling

Next week, the final episode of the series will be published, so be sure to check back. If you have any comments, please provide them below!

A quick summary of posts in this series:

1. Throwing Exceptions
2. Using Assertions (this one)
3. Catching Exceptions
4. Logging Exceptions

Guidelines for assertions

An assertion is code that’s used during development that allows a program to check itself as it runs. They are used much in the same spirit as unit tests, but spread out in the actual program code. It is a statement placed to indicate that the developer thinks that some predicate is always true at that place.

Use assertions for conditions that should never occur

Use a barricades to distinguish between assertions and exceptions

Don’t put executable code into assertions.

For highly robust code, assert and then handle the error any way

Assertions in Java

For those unfamiliar with assertions, I’ll give a quick summary. Java provides the keyword assert since version 1.4. It throws a java.lang.AssertionError when it fails, and has the following syntax:

assert expression : "error message shown if expression is false";

Where expression is any boolean expression which should always be true at the point of the assertion. For example, this variable should always be greater than 0, or that collection should always be empty.

To enable assertions when running a program, use the Java VM -ea (or -enableassertions) switch. Assertions are always compiled in, but without this switch, the assertions are ignored by the virtual machine.

Tune in next week for guidelines for catching exceptions! And please do write any comments or questions you might have below.

The series will cover what I think is a good and sound strategy for handling exceptions and errors in your application.

It is written with Java in mind, but is applicable to most languages which feature exceptions.

A quick summary of the coming posts:

1. Throwing Exceptions (this one)
2. Using Assertions
3. Catching Exceptions
4. Logging Exceptions

Let’s get started!

General

First, we’ll go through some things which apply to all types of exceptions.

Always preserve the stack trace

Never use exceptions for flow control

Provide enough context

Next, we’ll discuss checked and unchecked exceptions, and when to use them.

Checked exceptions

A checked exception is a Java concept which means an exception which is specified in a method’s signature. It is a way for the designer to tell the client of a method what might go wrong, so that the client can prepare accordingly.

Throw a checked exception if a method can’t fulfill it’s contract

Make your exceptions part of your contract

Never let implementation-specific exceptions escalate to the higher layers

Unchecked exceptions

Unchecked exceptions are all other exceptions, which are “unforeseen”.

Prefer unchecked exceptions for all programming errors

If the client cannot do anything useful, then make the exception unchecked

Feel free to provide any comments or thoughts below, and check back in a week for the next episode!

I originally intended to just comment that piece, but the sheer amount of comments made me realize that no-one would actually read it anyway. So I might as well write a response in my own blog which about as many will read but which makes me feel better.

I believe the answer is “yes”. I think that a competent programmer needs to be “mathematically inclined”. Not because the average programmer’s typical work includes much math such as applications in 3D, compression, and image manipulation. In those cases it is fairly obvious that a firm grasp of math is required. I believe the answer is “yes” because in my mind “mathematically inclined” also means “good at seeing patterns”, “good at identifying duplication”, “understands basic complexity theory”, or simply “good at groking thinks”. And while a good understanding of math in general is valuable, I think a solid understanding of discrete math and logic is invaluable.

Finally, I liked what the unnamed author mentioned in Jeff’s post wrote enough to reprint it here.

I run a small (4 people) web dev shop and I’m finding that younger coders haven’t had the pleasure of writing assembler or managing without library functions. I’ve always found strong math skills to be one of the most useful skills for coding, and when one has Google and a massive library of functions, one doesn’t have to be good at math to get things working, until it either breaks, has edge cases, or brings out OS or library bugs.

Some quick examples: simplifying tricky equations to determine array indicies or memory offsets; trigonometry to help with physical calculations; mental hex/bin/dec conversion; logic equalities such as DeMorgan’s theorem.

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 by postponing decisions until we have as much information as possible. In older waterfall processes, pretty much everything was decided upfront. That wasn’t because people thought it was so much fun to decide everything up front, but because they believed it to be the best way to reduce risk and cost. Because a bug found just before delivery is much more costly than one found earlier.

Agile, on the other hand, tries to use development practices which enable us to postpone decisions, practices which makes the system easy to change even later in the development process. Thus, the code you write should have two qualities:

• doesn’t force you into making unnecessary decisions, and
• be easy to change.

How to reduce risk the agile way

Quotes such as “You Ain't Gonna Need It” (YAGNI) and “Do The Simplest Thing That Could Possibly Work” (DTST) emphasize the first part — not making premature decisions. But while you can typically find people talking about the second part too, it doesn’t nearly get as much attention in people minds as the first one. Most likely simply because it’s not included in the name, in the mantra. I guess “You Aren’t Gonna Need It, But Do Not Forget To Make Sure Your Code Is Flexible” just doesn’t stick as easily.

Actually ensuring that your code is easy to change requires some work — especially while trying to avoid making premature decisions! It means using things like table driven code and putting abstractions in code an meta-data in configuration. It means thinking about what things are likely to change, and what things are not. It means not assuming too much, since you never know how things are going to be used in the future.

Where many people misunderstand agile

Rules and practices are good, but they are just the means to an end. I find that too many people interpret the agile mantras of YAGNI and DTST too literally. They create solutions which are “simple” and “works” and only includes “what’s needed”.

However, the next day, or next month, when requirements and expectations have changed (as they no doubt will) these solutions prove to be hard to adapt to the new situation. That’s because their developers forgot about the second part, making the system easy to change! And I believe forgetting that is forgetting the very core of what agile is about!

You agree? Got another opinion? How do you ensure you’re code is easy to change?

Låt oss föreställa oss en helt vanlig taxichaufför.

Taxichauffören har taxilicens och en taxibil som är registrerad enligt konstens alla regler. Det enda som utmärker vår taxichaufför är att han har en lite egen twist — han tar alla körningar och ställer inga frågor.

En dag får vår taxichaufför ett uppdrag: Kör till en given adress, vänta med motorn igång och kör därefter till en annan adress. Taxichauffören accepterar. Väl vid den första adressen ser han att det är en bank. Han ser också klart och tydligt hur hans passagerare är inne i banken, hotar personalen och tvingar dem att ge honom pengar. Men vår taxichaufför ställer ju inga frågor så han väntar tills passageraren är klar på banken och kör sedan passageraren till den andra adressen. Körningen är klar och taxichauffören åker hem. Han inser att han just kört en bankrånare till och från ett rån men är okay med det — han själv gör ju inget olagligt. Han kör ju bara taxi.

Efter denna incident återkommer både denna passagerare och andra personer som använder taxichauffören för att köra dem till och från rån, inbrott, stölder och andra brott. Taxichauffören fortsätter köra utan att ställa några frågor. Han får inte någon del av bytet utan tar endast ordinarie taxa. Han är medveten om att hans passagerare begår brott, men sover ändå gott om natten — han själv gör ju inget olagligt. Han kör ju bara taxi.

Vad tycker du om taxichauffören? Gör han något olagligt? Beter han sig omoraliskt? Kommentera och ge din åsikt!

PS. Angående något helt annat, Pirate Bay-rättegången pågår. Vad handlar den om egentligen? Pirate Bay-killarna gör ju inget olagligt. De driver ju bara en webbsajt. (Eller?)

PPS. Skivbolagen behöver tänka om! Stöd Spotify och andra lagliga alternativ och tala om för skivbolagen vad ni vill ha!

PPPS. Detta inlägg är ej avsett för barn, då de ej förstår ironi.

En kollega till mig surfade runt på gp.se och lekte med deras TV-spelare. I adressfältet fick han fick syn på en parameter vid namn insertUrl vilket genast fick honom att fundera.

Phishing

Misstanken var logiskt nog att man då kanske kunde visa inte bara GP-TV genom gp.se utan vilken sida som helst. Denna misstanke visade sig vara helt berättigad. Man kunde alltså få gp.se att visa vilken annan sida som helst inuti en iframe. Och att från en annan sida bryta sig ur en iframe:n är en barnlek. Phishing-attack, ja tack!

Cross-site scripting

Alright, inte snyggt, men det tar inte slut där. Utöver att de blint litar på den URL som användaren skickar in och glatt visar den i sin iframe, så hade GP gjort ett ännu grövre fel. De hade över huvud taget inte validerat sin indata. Detta är ett av de mest grundläggande säkerhetsfel man över huvud taget kan göra på en webbsida. Det ger en elak person möjligheten att köra valfri kod (html/css/javascript/activex etc) när en användare besöker sidan.

Allt anfallaren behöver göra är att få besökarna att klicka på en specialkonstruerad länk till gp.se. Denna typ av attack kallas Cross-site Scripting (XSS) och kan leda till exempelvis stöld av de konton som finns på gp.se, exempelvis administratörer eller annonsörer. Inte bra! Inte det minsta bra!

Kontakt med webmaster

Min kollega valde att kontakta GP:s webmaster och påpeka säkerhetsbristen, så att de skulle kunna åtgärda den. Detta gjorde han igår kväll och idag under förmiddagen fick han ett svar att de nu hade åtgärdat problemet. Dock fanns i svaret inte en tillstymmelse till tack. Det kan man ju tycka att de kunde kostat på sig.

Problemet finns kvar!

Efter en snabb titt på samma sida kunde vi konstatera att förvisso har de nu en kontroll på insertUrl-argumentet för att försäkra sig om att det är en giltig GP-TV-url, men att säkerhetshålet trots detta kvarstod. Det finns nämligen fler parametrar vars värde också sätts rakt in i HTML-koden som skickas ut till användaren. Så de är fortfarande precis lika sårbara för XSS-attacker!

Sammanfattning

Så summa summarum, GP lyckas skapa en sida som inte bara lider av ett stort säkerhetsproblem, utan två! Två problem som är fullständigt grundläggande när det gäller säkerhet på webben. När vi påpekar det för dem svarar de kallt att det är fixat… men problemet kvarstår!

Jag är egentligen inte ett fan av “full disclosure” gällande säkerhetsbrister, men det finns en gräns! När de helt lyckas missa grundläggande säkerhetshål inte bara en gång utan även en andra gång efter att fått information om att hålet existerar, då har de gått över den gränsen!

Definitions

According to Wikipedia, a cross-functional team is:

A group of people with different functional expertise working toward a common goal. It may include people from finance, marketing, operations, and human resources departments. Typically, it includes employees from all levels of an organization.

If we instead look at the definition of a cross-functional team in Wikipedia’s Agile Software Development article, we learn that such a team “is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members.” This seems to suggest that the meaning of cross-functional in agile is often interpreted a bit differently.

Why confusion arises

Part of the problem might be that leaders in the field are sometimes a bit unclear. For example, reading Henrik Kniberg’s otherwise excellent piece on agile testing quickly, you can easily get the perception that he is arguing for the generalist approach. Quotes such as the following certainly helps one reaching such a conclusion.

In agile projects, testing is considered to be far too important to be confined to a single role, a single team, or a single project phase. Having a role called Tester implies that others don’t need to test. In an agile project almost everyone tests.

On the other hand, if you read it more carefully, he is actually arguing for a specialist approach. (Although he plays safe — and increases confusion — by calling them generalizing specialists.) Anyhow, this quote gives a rather other feeling than the previous.

Since the programmers have automated all the boring, repetetive tests, you are free to focus on the hard stuff. The stuff that is difficult to automate. Exploratory testing. Usability testing. Performance test scripts. Figuring out those tricky test cases that only a veteran like you could come up with.

Finally, in his own words:

Agile teams are cross functional, they are made up of generalizing specialists. People who are experts at certain areas, but have basic knowledge of a whole bunch of other areas as well. A team of generalizing specialists is extremely fast at learning and adapting.

Why specialists?

For me, I’m in the specialists camp. As some form of evidence, I’d like to quote Marcus Buckingham and Curt Coffman from the great book First, Break All the Rules.

Great managers do not believe that a productive team has camaraderie as its cornerstone and team members who can play all roles equally well. On the contrary, they define a productive team as one where each person knows which role he plays best and where he is cast in that role most of the time. … The founding principle here is that excellent teams are built around individual excellence.

The nice part about this last quote is that it is not simply anecdotal “evidence”, but actually conclusions drawn by the Gallup organization after interviewing over 80 000 managers!

Your experience?

What’s your experience in the matter? Is specialist or generalist the way to go?

A few days ago, I a girl caught my attention on the tram. Now, a lot of girls catch my attention, but this time it wasn’t actually the girl herself but her shoulder bag which caught my attention. It happened to have a print which I thought was pretty funny.

Join a proud minority — read books.

First I thought that was rather witty, but then it actually made me sad. Are people who read books (by free will) actually a minority? If I restrict myself to the software development world, then apparently they are. According to DeMarco and Lister in Peopleware:

The statistics about reading are particularly discouraging: The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one. That fact is horrifying for anyone concerned about the quality of work in the field.

Consider if this would have been some other field, say medicine. Would you have liked to hear your surgeon say, “nah, I don’t really read books, I base most of what I do on reading blogs”. I sure wouldn’t!

Why you should read books

Alright, why should you read books? Why not just read blogs? Good question! And here’s why:

Books are better than blogs!

Now, that’s a pretty tough argument. Of course, I’m not saying that blogs are bad, but what I am saying is that so much more work has been put into the really great books than into any blog out there. Don’t waste all that work! By reading books, you will learn stuff you otherwise wouldn’t have and you’ll get a deeper understanding of it.

Now, don’t get me wrong. Blogs are truly essential and a great part of the internet. All programmers should consider themselves very lucky for having access to all that material. However, their content is typically only good after a couple of loops in the echo chamber (aka blogosphere). When you buy a (good) book, the material you get is already refined, it has already gone through all that necessary editing.

When not to buy books

You might ask yourself, why should I buy books which will be outdated in a year anyway? Also, there are no hyperlinks in books. Books suck! Well, in this regard, I completely agree. The answer is:

Don’t buy reference books.

Here I’m going to quote Jeff Atwood, because he explained it very nicely.

The best programming books are timeless. They transcend choice of language, IDE, or platform. They do not explain how, but why. If you feel compelled to clean house on your bookshelf every five years, trust me on this, you’re buying the wrong programming books.

How about you?

So, that’s my thoughts on the subject. What do you think? Do you read books? What is the best book you’ve read? The worst? Why? Answer with a comment!

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 me. Sometimes I’m lucky enough to get comments from these people on my posts. While I’m typically rather convinced by my own reasoning when I write the post in question, every time I get such a comment I am struck by how much smarter they are than me.

Recent cases where this has happened:

• Mike Cohns comment on Not Converging on an Estimate: I discussed an adaption of some advice he gave in a book. However, my adaption forced me to ignore other parts of the same advice. He pointed out that there was no problem in actually doing both parts.
• Full Statement Coverage: I wondered why Ron Jeffries was writing such sloppy unit tests in some of his articles. He didn’t seem to test even half of the code he wrote. A short email conversation later I had realized that he of course wasn’t sloppy, but rather just much more clever than I was.

So, I simply hadn’t understood what they meant the first time? I don’t believe it’s as simple as that. I think I did understand. Most of the time anyway. But my level of understanding just wasn’t as deep as theirs.

The upside is that every such moment makes me a little bit smarter! Have you experienced a similar situation? What was your latest “revelation”?

The steps

I tried to perform the following steps.

1. Define the scope of what you’re estimating.
2. As Mike Cohn suggests, ask each developer to make an estimate and write it down.
3. After everybody has made up their own mind, take note of all estimates.
4. Discuss the estimates if wanted, but do not revise them! (Unless someone completely misunderstood the scope.)

By writing the scores down and not revising them, developers do not get a chance to influence each other. If all of these original, uninfluenced, estimates are close to each other, you can probably be more secure with that estimate. On the other hand, if they are spread out you get an indication that risk is rather high. Estimating this way actually gives you more information, as you not only get a mean value from the estimates, but also a precision or confidence interval.

Related thoughts

Max Pool has been arguing for a similar approach, where you estimate in ranges. However, using the approach suggested above, you don’t have to set a percentage probability yourself (which might be a hard number to come up with) — you get it for free.

Furthermore, if you think about it, estimating with just a single value is almost meaningless anyway — you’ve always got a precision, that is, an interval. When you say that something will take “2 days”, what is the precision? Two days within a second? Minute? Hour? Day? Week? Also, is it an upper bound? Lower bound? Mean value? Using an interval gives you a good way of making these assumptions much more explicit.

What are your thoughts? Have you estimated using something else than a point value? Do you disagree? Let me know!

Update

In his comment below, Mike Cohn pointed out that I in fact can have my cake and eat it too. I can use the highest estimate as a “upper bound” and also continue discussing and re-estimating until everybody agrees on a single estimate. That way we get a range but do not lose the valuable discussion during the convergence.

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 whole idea than the more established “last responsible moment“. The latter suggests that you should delay making decisions for as long as you can. I feel that sends the wrong signal. You can make decisions. You must make decisions. Not making a decision is a decision in itself. Just don’t make decisions that you cannot change — keep your options open. By thinking that you must not make decisions until the “last responsible moment”, it is easy to delay the decision longer than is actually responsible.

I believe this is especially true for software architecture. In the name of “last responsible moment”, many developers avoid making architectural decisions, thinking the architecture will emerge by itself. But to quote Grady Booch in a response to a letter “The Relevance of Architecture” in IEEE Software (Volume 24 Number 5).

Every system has an architecture; some are accidental, others intentional.

Which is yours?

The problem with this comparison is that it’s simply wrong. I’m fine with comparing creating software with creating a car. But the closest thing to an assembly line in software development is the work done by build and deployment scripts, turning source code into executable software. The actual analysis, design, and coding corresponds to developing a brand new car model. It is a creative process without a single given “right answer” and of which experimentation and iteration are natural ingredients.

To use another metaphor, and at the same time cite Mary and Tom Poppendieck from their book Lean Software Development:

Development is like creating a recipe, while production is like making the dish. Recipes are designed by experienced chefs who have developed an instinct for what works and the capability to adapt available ingredients to suit the occasion. Yet even great chefs produce several variations of a new dish as they iterate toward a recipe that will taste great and be easy to reproduce.