Teamwork

The fundamental practice of teamwork remains essential.  Agile succeeds in large part by reducing wasted effort, and much wasted effort is the result of various people pulling in different directions.  Even slightly different directions will create enough friction to noticeably slow the project.  It’s well worth spending some time and effort on building an effective team within the context of the project.  The two practices most essential for supporting teamwork in an Agile transition are working with a whole team in a common area.

Whole Team

While collaborative teamwork among all the developers, for example, is beneficial to any project, it’s not enough to accomplish a transition to Agile.  At a core, you’ll need high-bandwidth collaboration between your Product Owner, Scrummaster, and Developers.  This is the minimum, in Scrum terms.  In most organizations, Developers really includes both programmers and testers; in some it includes user experience designers.  Yours may include people with other titles, such as architect, database administrator, security officer, system administrator, operations engineer, technical writer….

Your project community will also consist of other stakeholders, such as executives, customers, end users, support personnel, other development teams, facilities maintenance…. There are a lot of people with interest in the project or the things that the project team is doing.

The boundary between the core team and the rest of the project community is rarely distinct.  One useful distinction is whether a person is focused principally on the project, or whether the project is just one of many things with which the person is concerned.  This distinction is not without peril, however.

All too often an organization will assign multiple projects to people where it would be much better if they were focused on one.  If you give your Product Owner, your programmers, or your testers multiple simultaneous projects, you’re likely headed for trouble.  You may be headed for trouble if you multi-task in some of the other specialties, but there’s more variation from one context to another.  As a rule of thumb, if there is any way to let someone focus on only one project, then you should do so.

Common Area

Building a team, which is different from a mere work group, takes a lot of work.  With skill, you can facilitate that teambuilding to help it happen more reliably and a little faster.  If you don’t have a skilled facilitator, though, you’re still in luck.  People have practiced self-organizing into small groups for their common good for millennia. If they’re working together for a common goal in a common area, distinct from those working on other goals, they’ll likely build a gelled team without an outside facilitator.  There are many reasons for this, from trust building to osmotic communication.

“But we can’t do that,” I hear you cry!  Why not?  Is this project, this Agile transition, so unimportant that you can’t sit together?

“Our Product Owner has an office elsewhere, and needs to attend to other things.” Maybe you’ve chosen the wrong product owner.  Maybe the Product Owner can sit in the team room for part of the day.

“Our project team is scattered around the globe.”  Don’t do that.  While it’s possible for people scattered around the globe to work together, it’s much harder.  The odds of making that work while also making an Agile transition are slim to none.  If you must do distributed projects, set up a collocated team at each location and minimize the working dependencies between the teams.

“We don’t have a space that supports that.”  Find or make one.  Move furniture.  Take down cube walls.  Set up temporary or movable partitions.  If the furniture arrangement is more important than the project, consider canceling the project.

Visible Progress

In order to see whether or not we’re headed toward our goals, we need visibility into the progress.  Usually, this boils down to the questions “Are we going to get everything done?” and “Are we going to get done in time?”  If the answer to one or more of these questions is “no” then we can make adjustments to how we’re doing things, how much (and which things) we expect to get done, and what time we expect to have them done.  We can subdivide this visibility into two simple practices: taking baby steps and getting things done.

Baby Steps

Everything we do, from releasing interim versions down to validating the code we write, we should do in small steps.  Working in small steps gives us a much finer-grained view of the progress.  It lets us view the initial trends sooner.  It lets us view changes in the trends sooner.  It gives us more opportunities to make corrections or course changes.  It gives us more practice and comparing where we’re going with where we want to go, so we get better at doing that.  It requires less work before we see that we’re doing something wrong, or doing the wrong thing, therefore there is less work to be thrown away and redone.

Done

There’s little point in measuring something as progress unless we know that it actually contributes toward reaching our goal.  Measuring amount of work done doesn’t tell us that.  Consider this scene from the movie, Captain Ron:

Captain Ron: We should be okay. ‘Cause I know we’re near land.
Martin Harvey: Great, Cap. Great. Ya hear that? We’re almost there. Explain to the kids how you know that, Captain Ron. Someone translate for General Armando.
Captain Ron: Alright, now stay with me: When we left, we had just enough fuel to make it to San Juan. And we are out of fuel.

The gap in that logic is immediately obvious, but plan-driven projects attempt the equivalent all the time. We must measure relative to the goal, not relative to the path we’ve taken.

It’s important that we measure functional slices. It’s often tempting to measure tasks that have been accomplished. Sometimes, however, these tasks turn out to be unnecessary, and they don’t contribute to accomplishing the goal.  Sometimes, while they look right in isolation, they turn out to have flaws when we look at the bigger picture.  Sometimes they don’t quite meet with other tasks, and there is a gap to be filled between the tasks.  Such a gap in unknown undoneness.

We need ways of seeing progress that won’t like to us about how much progress we’ve made, or how much is left to do.  We want to measure functional slices that go all the way through the system.  It’s easy to neglect some of the things that people think of “someone else’s responsibility” after the system is “complete.”  These things might include an installation procedure, or deployment to a different computing environment.  Sometimes people neglect something so basic as testing that the system works.

We want to see functional progress–something we can demonstrate and test, something we know is desirable.  Expending the amount allotted is not such an indication.  Getting most of the way to the goal is no guarantee that we’ll get the rest of the way there–particularly when the remaining part is fundamentally different than what we’ve been doing.  We want to always, or at least at frequent intervals, be able to stop and have something that can be used, even if incomplete.

Putting these together can be difficult for a team making a transition to Agile.  It’s hard enough to get everything working, but much more so when you’re having to do that all the time.

Fortunately there are a lot of well-known engineering practices to support combining baby steps with getting to done at each step.  I’m starting with the assumption that the team is already capable of creating working software using whatever techniques they already know.  Eventually they’ll need to learn other practices to support this new way of working, and even to get better in general.

Continuous Improvement

Being able to work as a team and measure progress in a visible manner is only the start.  At first, we’ll do these things in a rather rough manner.  As the system grows in size and complexity, that rough manner won’t sustain forward progress.  We’ve got to get better in order to keep moving.

And there’s no limit to how good we can get.  No matter how practiced we are, there’s further improvement we can make.  If we conscientiously practice our techniques, we’ll see places where we can improve them.  We can then practice those improvements, so they become a part of our routine, and we do them even when distracted by the latest disaster.  When things go wrong, it’s no time to ease off on the practices that make us more effective.

As a team, we need to take stock from time to time to see the longer term trends, both good and bad, and the issues that only become visible in retrospect.  Holding retrospectives at various tempos–each iteration, each quarter, each release–will give us various views into what we’re doing, and result in different insights.  We must use these insights to plan ways in which to improve in the future.

From these starting points of teamwork and visible progress, and proceeding with a program of continuous improvement, we can learn all of the practices that support Agile development.

Agile requires the courage to make mistakes in front of others and the maturity to admit them when they happen.

Surely this is true.  Agile is all about paying attention to what happens and adjusting for it.  We learn most when when thing are a little off from what we want, we notice that, and we correct for it.

Brian Marick responded

I now think that Agile requires the creation of an environment in which admitting mistakes doesn’t require courage.

Surely this is also true.  If we want people to notice when things are a little off, so we can make a correction, then we have to make it easy to talk about our mistakes.  If we don’t, the little mistakes get swept under the carpet and we continue on our way–until the mistakes grow so big that we can’t ignore them any more.  By this time we’re way off the path we want.

In other words, well, in my words,

I think Agile requires creating environment where admitting mistakes requires no more courage than you have.

We can’t eliminate the need for courage to admit our mistakes.  It’s human nature to gloss over even tiny ones, and hope no one noticed.  But we can reduce the stigma of making mistakes.

How fascinating!

was the comment by Willem Larsen.  Willem and Evan Gardner are spreading Evan’s “Where Are Your Keys” language fluency game.  It’s expected that you’ll make mistakes when learning a language.  The response to such a mistake is “how fascinating” signed by raising both hands in the air.  Everyone laughs.  No one feels badly for making a mistake.  In fact, it feels good to share your mistakes with a laugh and helpful colleagues rather than to hide it inside.

Is that the way it feels when you make a mistake in your team?  What could you change so it does feel that way?

One reasonable definition of good design is testability.  It is hard to imagine a software system that is both testable and poorly designed.  It is also hard to imagine a software system that is well designed but also untestable.

I greatly sympathize with this statement, though I wouldn’t go quite that far.  I don’t think it is so hard to imagine code that is testable, but poorly designed.  For a trivial counter-case, there could be rampant duplication of testable code.  I would call that poorly designed, but it doesn’t affect it’s testability.  Therefore I would soften Uncle Bob’s definition to “One reasonable component of the definition of good design is testability.”

To me, the notion of “testable code” is the same thing that “testable circuit” was back when I worked on a custom integrated circuit.  Mostly, that depends on the ability to put the circuit or code into a known state, exercise it, and see the interactions with its collaborators and its resulting state.

For ICs, the first level of making a circuit testable was to the internal state predictable and discernible.  Sometimes this was accomplished simply, by having the power-up state known, rather than random, and by being able to clock internal nodes into a shift register to be read out on an output pin in a special test mode.  That was enough to make it testable, but not generally enough to make it easy to test.

Being able to drive internal nodes to various known states gave a lot more power, allowing “unit testing” of various blocks of circuitry.  This generally required some additional hardware added just for testability (a point germane to the original question), but paid handsome dividends in reduced time to test units in production.

With ICs, much of the expense is in the packaging, and that expense was significantly related to the number of pins.  Testing equipment evolved to do the equivalent of “the bed of nails” used on circuit boards, but applied to pads on the circuit die that were never bonded out to pins.  This allowed easier access to internal nodes, both for driving state and for reading it, prior even to slicing the wafer into individual chips.  The heads that probed the circuit had a small nozzle to spray dye on failed circuits so they could be discarded before packaging.

With software, the ability to drive and access internal nodes is much easier–often not requiring any additional logic.  Sadly, many programs manage to make these internal nodes inaccessible, in spite of the lack of cost to do otherwise.

So, when I talk about testability, that’s what I mean.  And that’s why I quibble slightly with Uncle Bob’s assertion that testable code is necessarily well designed.  The converse is pretty easy to believe, but there are cases where, for no apparent reason, the design still sucks.

Well designed code, like well designed circuits, contain the complexity better and are therefore easier to adequately test.  This is, to me, an important point.  We’re very likely to miss stuff.  Let’s make it as hard as possible to miss stuff.  And let’s make it as easy as possible to notice when we’ve missed stuff.

In the words of C. A. R. Hoare,

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

Adam Sroka stated his discomfort with calling code testable unless it was, indeed, tested.  Again, I’ll be happy with a slightly lower standard.  It can be apparent that some code is testable even when not tested.  Generally, that code needs to be simple enough that testability can be obvious.  In most cases, though, code that isn’t tested is also not clearly testable.  To a first order approximation, both Uncle Bob’s and Adam’s statements ring true. I’m not terribly concerned with the absolute truth of either of them.  I do, however, prefer Michael Feathers’ assertion that there is a deep synergy between testability and good design.

As is often the case, we must back up and take a larger systemic view to see further.  Once upon a time, people borrowed money to buy a house, paid it back over time, and ultimately the bank was able to lend that money to someone else.  With the creation of the FNMA (Fannie Mae) in 1938, the income streams of those mortgages being repaid were converted to bonds, so that they could be sold to other investors and the banks to re-lend their money more frequently.  This allowed many more people to afford houses.  In the 1970s, private banks got into the business of creating their own bonds based on debt repayment streams.

Nothing ever stands still, of course.  People continued to look for new wrinkles on these themes to allow them to expand the business, or to increase the profit on the business they had.  Some of these investment vehicles got very complicated, intended only for professional bankers who could understand and evaluate them where the mass public could not.  Or, so went the pitch at the time.

As it turns out, many of those professional bankers couldn’t fully understand and evaluate these instruments, either.  And this is in spite of reams of financial reporting about the quality of the underlying mortgages, the default rates, and other things that might affect the debt repayment streams.  No one has time to read the reams of financial reporting.  Instead, they simplify it, and boil it down to a relatively few values and ratios that they do read.  These derivative indicators became proxies for a real understanding of the risks and rewards of bonds based on mortgages.  And then there were derivative financial instruments based on the bonds based on the mortgages, and they had their own proxies for the risks and rewards.  I don’t know how many layers there are to this particular onion, but I do know that, at some point, the proxy measurements diverged from the real understanding of the risks and rewards.

Where have I seen this phenomena before?

I’ve seen it in businesses that couldn’t quantify the actual value of the software systems they were building, so they substituted the cost of building them as that value.  I’ve seen it in project managers who couldn’t quantify the actual productivity of their developers, so they substituted proxy measures such as “hours worked” and “lines of code” as an indication of productivity.  I’ve seen it in project managers who couldn’t quantify the actual progress of a project, so they substituted conformance to their original plan as a proxy.  And for individual items on that plan, when they couldn’t discern the actual progress on an item, they substituted reports of “percent completion” as a proxy.

All of this makes perfect sense at the time.  There is some correlation between lines of code and productivity.  And by using proxies that are quantifiable, we can crunch the numbers and come up with a few key indicators to let us know how we’re doing on productivity, progress, and value.  And we can calculate the amount of risk we have, at least, the amount that we’ve anticipated.  We end up with a handful of indicators that make us feel on top of things and in control.

And, like in the financial industry, as long as things keep going well, these numbers seem to work for us.  But we have no way of knowing how much and in what ways our proxy measurements vary from the things that really concern us.  And we have no way of knowing what risks are not included in our numbers.  And we have no way of knowing in what ways the future might differ from our increasingly successful past.

There were those who took a systemic look at the financial industry and predicted that trouble was coming.  As the system mutates over time, it rewards behavior that varies from what we really want.  The increase in that behavior then drives further changes in the system.  It’s a lead-pipe cinch that the future will differ from the past.  But looking at proxy measures won’t tell us that.

“The prudent mariner will not rely solely on any single aid to navigation, particularly on floating aids.”  This advice used to be printed on all US nautical charts.  It’s good advice for the prudent manager, also.  Proxy measures are like floating aids to navigation.  They only give an approximate position, as they drift around their anchor point.  And sometimes, unseen by us, the anchors themselves drift from the known location where we set them.  As we reward lines of code or hours worked, these measures drift further and further from a representation of productivity.  As we measure conformance to plan, then that conformance becomes more important and accomplishing the goals that the plan was created to accomplish becomes less immediate.  That conformance then becomes a poor proxy for accomplishing our goals.

So, look around.  Find some other aids to know where you are, and where you’re heading.  Don’t wait until it’s too late to prevent disaster.

We must actively challenge the mindset of divided responsibility–” You spec and design it; we’ll build what you spec.” Everyone should work toward the shared vision of a successful experience.

That says so elegantly what I tried to say in my article.

As long as projects are staffed and led by people, we can be sure that they will sometimes get stuck, or headed in the wrong direction, or something.  This is true no matter what sort of methodology you follow.  Even if the methodology is perfect, the people following it are not.  They will make mistakes.  They will have blind spots, and not see what it is that they’re not seeing.  Projects will still get in trouble.  (Yes, even Agile projects.)

So, what do you do about this certainty? Jerry suggests The Clinic Method.  What’s this?  It’s a nurses’ station for projects that are sick.  If a project manager or product owner or scrum master or anyone feels that a project is in trouble, it’s a place to go for help.  Get five or six of your best people and have them meet for half a day, once a week.  Choose people who are

• good problem solvers
• good communicators
• good decision makers
• and who understand the business

Don’t choose everyone by the same criteria–you want diversity on this team.  You can also rotate people through this committee, but on a staggered basis so you don’t change them all at once.  Publicize this meeting so that anyone with a concern can attend and ask for help.

What does this team do when someone brings a problem?  They don’t solve the problem.  They help that person come up with a positive step to move forward.  Remember:

The problem is not the problem.  The coping with the problem is the problem.

So you dig down for the underlying issues.  You triage the issues and pick out what’s a real bottleneck.  And you help the person in need come up with some strategies for a solution, and at least one step they can take immediately.  That step may be a small as gathering some necessary information that they don’t have, and bringing that information back the next week.

We played roles and gave this a try.  I was fortunate to have an opportunity to play both a person with a problem, and a person on the clinic team.  Being on the clinic is not easy.  You have to think hard, and bring all your experience to bear to generate insights.  And you have to listen and understand what others are saying (or not saying), both those who bring problems to you, and those who sit on the clinic with you.  Remember, this is not just a job for anyone, but for some of your best people.  It doesn’t even have to be an officially sanctioned body of the organization–in most organizations of size, your best people can make this happen on their own.

And if no one comes with a problem?  Go looking for them.  They’re out there.

The statement

“For a project to take interaction design and usability seriously, it must assign them ‘story points’ (i.e., resources) on an equal footing with the coding”

jumped out at me.  Alistair Cockburn wrote a thoughtful reply where he noted the same statement.  I agree with Alistair’s comments, but I’d like to comment on this statement from a slightly different perspective.

First of all, story points do not represent resources applied.  They’re an estimate of the work required to accomplish a small but measurable increment of functionality.  This work has never been just “coding.”  At the very least it includes testing and acceptance by the Customer.  If the functionality includes a change to the UI, then figuring out what that UI change should be is also part of it.

Many shops don’t have UI experts, so figuring out that UI change falls to the developer and the Customer having a discussion and making a decision.  Yes, this sometimes results in a terrible UI from a usability point of view.  The good news is that, if you’re working in small increments in an iterative fashion, you can always revisit this and change it.  If it’s bad enough, this usually happens.

When there is a UX/UI designer, their work is too-often treated as an up-front requirements definition phase, handed to the development process as a fait accompli to be developed without any further discussion.  The problem with this is not that it’s not “Agile,” it’s that it sabotages the benefits that people seek when they adopt Agile.  The Customer might have made some subtle adjustments to the functionality of the story, and the pre-designed UI might no longer be so appropriate.  The precisely-defined UI might be really expensive to develop, and a much cheaper approach might be approximately as good.  And, if the story is never scheduled for development, this up-front design is completely wasted.

It appears to me that the only way to get the Agile benefits of balancing needs and costs to get the best bang for the buck, is to move this UX/UI design work into the incremental, iterative development cycle.  That doesn’t mean to create a separate story card for UI design, and then another for implementation.  The completion of the story includes the UI design, the implementation, the testing, and the acceptance by the Customer.

“But,” some designers protest, “we need to do usability testing with mockups to know which is the best design.”  Well, perhaps.  On the one hand, with enough experience you might be able to design a “good enough” UI without this step, particularly if you know it can be changed in the future.  Doing the usability testing with live code, rather than a mockup, might provide better feedback because it tests the concept as-implemented, rather than as-conceived.

Sometimes, of course, we just won’t know enough to jump right to code.  This happens with coders, too, and we have a tool to deal with this situation.  That tool is a “spike.”  This is a time-boxed exploration to learn what we know we don’t know.  For a coder, it may be coding up an alternative implementation to see if it will work, or if it will provide advantages.  For a UI/UX designer, it may be creating and testing a low-fidelity prototype.   It’s time-boxed because it’s not directly producing value–it’s producing knowledge that we must then leverage to produce value.  Our goal is to answer some questions, not produce the best possible prototype.

When Nielsen recommends,

Most successful teams have adopted a parallel track approach, where the user experience work is continuously done one step ahead of the implementation work. So, by the time such teams start to develop a feature, the initial user experience work on it has just completed.

I think that he’s offering a half-step toward a more agile, effective approach.  While doing the UX work “one step ahead” is better than six month’s ahead, it’s treading on the same slippery slope as doing acceptance testing “one step after” implementation.  Splitting these concerns into a three-iteration waterfall makes the presumption that the work done in one iteration will not be affected by the associated work done in another.  This is rarely the case.  Even William Royce’s classic paper, Managing the Development of Large Software Systems, which described the approach now called “waterfall,” shows feedback from one phase to the previous.  The work done in implementation may inform the UI design and the work done in testing may inform both the UI design and the implementation.  Either the story is not done-done or it drags on for more iterations, being handed back for re-work.

Most successful Agile teams have learned to incorporate testing in the same iteration as development.  Sure, it’s less convenient that way.  They always struggle to keep these aligned without resorting to a mini-QA phase at the end of the iteration.  The developers and the testers have to take the bigger picture into account, and not focus solely on their own tasks.  It’s more difficult, particularly at first, but it’s more effective.

In the same way, Agile teams with UX/UI experts can incorporate UI design into the same iteration as development.  Those UX/UI experts will have to look at a bigger picture than just their area of expertise.  They’ll find this more difficult, especially at first.  But it will be more effective.  There will be times when they need to answer some questions before a story is ready for development.  In those cases, they should do a low-fidelity prototype spike to answer the questions they have.  It may be that the knowledge gained from that spike will mean the story itself is scrapped.  Or it should give them enough information to proceed with the more detailed design with the developers who are implementing it.  They might even consider measuring the actual implementation with usability testing in the same iteration, along with the functional testing that is part and parcel of calling the story done.

So, usability experts, are you up for the challenge?  Are you willing to stick your neck out and take responsibility for the usability of the delivered software?  Or are you going to take the easy route and say, “I did my task; the developers just didn’t follow my directions properly.”   I’ve heard that for years from people who fancy themselves as architects.  I don’t buy it from them, either.  Those who would be experts in design have a responsibility to see that design through to successful deployment.  Anything less doesn’t count.

• Put your actions to improve on story cards and add them to the iteration backlog.

I wouldn’t want to give them story points (I also don’t like to give story points for engineering tasks), but this is a way to keep them visible and get them done. It also requires that they be actions, rather than just wishes.

• Ask people, not what is the biggest or most important problem, but what do they have the energy to improve.

The biggest problem is often too daunting to tackle. That’s why it seems the biggest. Instead, pick something that seems important, but doable.

This reminds me of the way I often approach the refactoring of large or old legacy code bases. Often I find that I can’t make any headway on what seems like the most fundamental problem with the code. When that happens, I start chipping away at smaller issues, isolating problem areas into relatively distinct chunks. Ultimately, when enough of these smaller issues have been tackled, the big unapproachable refactoring no longer looks so big.

There’s lots more there than what I’ve mentioned here. I recommend that you go give it a listen.

As always, I have to stress that this is not a moral issue but one of pragmatics.

As I read through the comments on this post, I came across one that noted this was a case of

The classic fight between short-term “success” and long-term prosperity.

Suddenly I was struck by the parallels between this dilemma faced by business owners and those faced by software developers.

Imagine it’s getting late, and you’re tired from a long day’s work. A feature you’re implementing has exceeded your estimation. It should have been done by now, but there were some unexpected complications and you’re still working on it. You just want to get it done and go home, right?

Do you

1. make it pass the test, check it in, and go home, or
2. think about how this code fits into the bigger picture, and why you ran into those unexpected complications, make this code clearly reflect this code’s role in that bigger picture (perhaps extracting a class to explicitly acknowledge a secondary responsibility), as well as making it pass the test.

Which is better for long-term prosperity of the code?

Have you faced this dilemma before in this code base? Are those unexpected complications a consequence of code that was left a little less than clear in the past?

The discussion I mean started in the middle of another thread, when Clay Dreslough asked about Pair Programming.

But I have never had any success with actual Pair Programming.

So … am I missing a key component of XP? Or have other people found the same reticence with adopting Pair Programming?

Are there some valuable gains here that I’m missing? And if so, how would you recommend getting programmers to change their habits?

Very reasonable questions, in my opinion. And so I branched the thread to one about pair programming, stating that I did, indeed, think there were valuable gains that were being missed. But rather than start with discussing the value of the practice (which doesn’t necessarily persuade people to try it) or specific techniques of pair programming, I asked about the context in which it had been tried and the experiences that resulted. Rather than give a sales presentation, I wanted to compare experiences so that we could each learn from the other.

Surprisingly enough, this triggered a response from someone else, ranting about zealotry, one-size-fits-all practices, and people-over-process that caught me totally off-guard. It was as if the very mention of pair programming on a scrum list was forbidden territory. Certainly I had said nothing about the practice being essential. And I’ve found pair programming to be an incredibly people-centric practice that defies attempts to control exactly how the process is followed.

I hope that the discussion will return to pair programming, itself, but the issue about whether it’s permissible to discuss a topic is also an important one. As I said there, talking about experiences, whether successful, unsuccessful, or somewhere in between, can help people learn and choose. Making such discussions forbidden is as much an indication of zealotry as is an insistence that a practice must be followed. Or, perhaps, more so–for a wise person can learn from the one-sided exhortation of a zealot more readily than from the silence of a forbidden topic.

Or, as Robert Frost was recently quoted on the XP list, “Education is the ability to listen to almost anything without losing your temper or your self-confidence.”

As he was a new member of the team, I described the strategy I’d planned for a bit of code. I showed him what I’d already written, and asked him to complete the functionality.

“But I can do it another way.” And he described a different technique.

“Yes, but they’re already talking about changing this piece. Though it’s a little more code, this way is simpler and easier to change. It keeps the knowledge of the screen layout configuration in one place.”

“OK.”

Later, when I was reviewing code that had been checked into the source code repository, I saw that he’d done it his way. He has also left the beginnings I’d asked him to complete, though it wasn’t used anywhere, as dead code. And when I brought up the fact that he’d increased the coupling in the system, since now the database had to understand the details of configuring the screen layout as well as the code, he asked, “What’s coupling?”

I think that instead of seven years’ experience, he had one year, seven times.

As I write this, I’m reminded of a day when I was a teenager. The father of a friend needed to pick up a van from across town and bring it home, but he didn’t have anyone available to drive the second vehicle. He offered me a few bucks to go with him and drive the van back. “Sure.”

I was following him back, when he suddenly took an unexpected turn. “Where is he going?” I wondered as I continued on my way.

When I pulled into the driveway, his car was already there. He came out of the house saying, over his shoulder, “Never mind; here he is.”

What an idiot I was! Why wasn’t it obvious to me that he’d been over this ground many times and knew all the roads to his own house. I knew only one. Because I knew only one, it was THE way. I had been so proud of myself for knowing THE way that I’d bypassed an opportunity to learn more.

My friend’s father never hired me for another errand, either.

I’d like to say that, now that I’m older and wiser, I don’t do things like this any more. Perhaps I do it less, but I’m well aware that sometimes I pass up learning because I think I already know THE answer.

Do you have a story where you passed up a learning opportunity because you thought you already knew the answer?

But the fact that the construction has run slower than expected is not the reason for this post. Neither is the fact that this project has been consuming a large portion of my attention, and hindering posts on this blog.

This post is about an example of refactoring found in the house construction domain.

Here’s a photo
of the west wall of our new house as originally constructed. Notice that there are three separate headers, one over each of the window openings and one over the door opening. The builder decided that this wouldn’t be rigid enough, and had the framer’s refactor this design to
a single microlam beam across all the windows and doors. I wasn’t in town when this was accomplished, but I would have loved to see how they did it.

In any event, it’s a classic example of refactoring. The design is improved, but the function is unchanged. And it was done in place, without deconstructing and rebuilding.