Absolutely No Machete Juggling

One of the most common sources of tension between product owners and developers is when product owners are surprised at how high an estimate for a story might be. Usually this tension is easy to resolve by reiterating that the product owners really have no concept of how much something should cost. However, there is one scenario I see over and over again: when a product owner protests the estimate of a story because it seems, to the PO, like it’s simply re-using an aspect of the system somewhere else.

“I already paid for that!” he or she might say, quite correctly. A simple example recently for us here was our column picker. Our grids allow you to select which columns you wish to see on any given grid. Later on, we created the ability to have grids inside of panels on user dashboards. Our product owner wanted to put the column picker on the settings pane of a grid panel. To him, this was simply reusing the column picker that had already been created for an earlier story. He was quite shocked when our estimate for the effort was just as high as it was the first time.

His frustration is completely understandable. How is this possible? Why isn’t it easy to just drop that component into another place and have it work? After all, if we were good engineers, wouldn’t we have written that component to be reusable?

Actually, no. It’s because we were good engineers that it wasn’t written in that way. This is one of the hardest things for product owners to understand, and I hope to explain it in this post.

The thesis for my Master’s degree in Software Engineering is finished.

It’s the result of many months of research, I hope others may find it interesting and informative.

Abstract

Test-Driven Development is a Software Engineering practice gaining increasing popularity within the software industry. Many studies have been done to determine the effectiveness of Test-Driven Development, but most of them evaluate effectiveness according to a reduction in defects. This kind of evaluation ignores one of the primary claimed benefits of Test-Driven Development: that it improves the design of code. To evaluate this claim of Test-Driven Development advocates, it is important to evaluate the effect of Test-Driven Development upon object-oriented metrics that measure the quality of the code itself. Some studies have measured code in this manner, but they generally have not worked with real-world code written in a natural, industrial setting. Thus, this work utilizes Open Source Software as a sample for evaluation, separating Open Source projects that were written using Test-Driven Development from those that were not. These projects are then evaluated according to various object-oriented metrics to determine the overall effectiveness of Test-Driven Development as a practice for improving the quality of code. This study finds that Test-Driven Development provides a substantial improvement in code quality in the categories of cohesion, coupling, and code complexity.

Download

If you’d like to read it, you can download it here:

Quantitatively Evaluating Test-Driven Development by Applying Object-Oriented Quality Metrics to Open Source Projects

As I grow through my career as a software developer, I have tried to remain aware of what makes me happy or unhappy at a job. What I decided was that there were three factors in job satisfaction, so I found myself amazed that someone else had posted something similar: Alan Skorkin explains his Three Pillars of Job Satisfaction.

I agree that there are three pillars, but I disagree about what the pillars are, at least for myself.

I’ve found that these are the main three factors in determining how happy I am at a job:

1. The People
2. The Project
3. The Company

Some of these may seem redundant, so let me elaborate.

Continue reading ‘My Personal 3 Pillars of Job Satisfaction’ »

Change is inevitable in the world of software. In fact, the need for change and the related need to adapt to change are the driving forces behind the agile movement. Requests for change generally come in one of two main forms: enhancements and defects. A defect means “the software isn’t working the way it says it will”, whereas an enhancement basically means “the software isn’t working the way the customer wants.”

The basic cycle of modern software development looks like this:

1. The customer tells the development team (often through a product owner) what he or she wants the software to do.
2. The development team responds to this by telling the customer what it will do (via direct conversation, help documentation, the UI, etc).
3. The development team makes the software do it.
4. The customer tells the team how well it did.

It’s step 4 that generates change requests. The customer says that something isn’t working the way they want it to be working, and the cycle repeats.

Very often, you will hear developers whine about enhancements that are being filed as defects. Product owners will often respond by saying that it doesn’t matter, it all has to be fixed. A common phrase I hear is “they are all defects from the customer’s perspective.” This mentality is echoed in Practices of an Agile Developer. The attitude is generally, defects and enhancements are basically the same thing, it’s all work that needs to be done, and programmers are being pedantic when they insist on making the distinction.

But here’s the deal: the programmers are right.

Continue reading ‘Enhancement vs. Defect: More Than Pedantry’ »

Andy Hunt's "Pragmatic Thinking and Learning" is a programming book only in the most liberal definition of the phrase. Sure, it's geared toward programmers, but the fact of the matter is that this book would be useful to anyone.

The book essentially covers two topics. The first topic is how your brain works. This is interesting, to be sure, but the book really shines when it comes to the second topic: how to use your brain, knowing how it works.

Andy talks about very light cognitive science, and he puts it into extremely digestible terms. I never felt lost, but I never felt patronized either. I emerged from reading the book with a far better understanding of the brain in an academic sense.