Monday, November 12, 2012
A common complaint against Test Driven Development is that writing tests and refactoring take too long. In the long run, I’ve found that TDD has improved my skills such that I can complete work faster by writing tests and refactoring than without. I’ve also found that this information is a weak argument for those who have less confidence in their skills, or feel too pressed for time to learn. But that’s not the only benefit. (Continued)
Monday, March 12, 2012
Ward Cunningham originally coined the term Technical Debt and described it at OOPSLA 1992
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
In this, Ward was not referring to poor programming practices, (Continued)
Thursday, January 5, 2012
Oops! The whole problem started when I wanted to install a new program on the “entertainment computer” that’s connected to the TV. The existing version of Ubuntu was no longer supported, so I started what I thought would be a simple upgrade. Oops, it deleted the entire /var directory, including the contents of the second drive mounted there. That drive contained all of our photos and music. Not a problem, I thought. It’s all backed up nightly onto a USB drive. It’s just a bit of bother to copy all of that over the USB interface.
Oops! There are no photos beyond last March. I felt sick to my stomach. That’s a lot of family memories to evaporated. Whew! The program we’ve been using to download the cameras also makes a backup copy local to the machine used to download. I’ve got all the pictures back on the photo server, and now just have to sort them into directories again.
But first, I need to fix the backup script. Why didn’t it warn me when it started to fail? (Continued)
Sunday, July 10, 2011
Southwest Airlines has long been known for two things: low prices and attention to customer service. Since they instituted the “reserved place in line” so I wouldn’t have to stand for a long period of time, I have come to check their website first, and only rarely look for alternative flights. Sadly, they’ve taken their eye off the ball. I suspect that the focus on customer service has been replaced by a focus on growth (given their in-progress takeover of Airtran).
Tuesday, June 14, 2011
Also while in Las Vegas for the ADP/West Conference, Bob Payne and I sat in the Agile Philanthropy booth and recorded a podcast on Acceptance Test Driven Development and the 3 Amigos. This is the latest in a series of Tips and Advice podcasts that Bob and I have done.
Wednesday, May 25, 2011
Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with
- A list of features to be built
- A release plan or timeline for those features
- Setting up development infrastructure such as version control or continuous integration servers
- Studying or practicing skills in new technologies they expect to use
- … and other management, infrastructure, and technical endeavors.
They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project. The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.
And we’ll have burned an iteration without producing any working software that tests our decisions.
My advice is to borrow an idea from Lean and look at the situation from the output point of view. Ask yourself, “what would it take to start delivering?” (Continued)
Tuesday, May 17, 2011
Michael Feathers has just written a post on The Carrying-Cost of Code: Taking Lean Seriously. He says,
No, to me, code is inventory. It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.
I’m not sure I can see the analogy of code that’s in production to inventory. Code that hasn’t shipped, yes.
But all code is a liability, I think. When code is in production, then it’s offset by the asset that is the functionality. Whether or not the net is positive is another question.
There’s no doubt to me that code, whether in production or not, has carrying costs that are larger than generally realized. Perhaps it’s a depreciating capital expense?
Carrying costs are larger than we think. There’s competitive advantage for companies that recognize this.
It’s something that takes up space. It takes maintenance. It takes attention. It does have a substantial cost of ownership–larger than we think.
The analogies may be failing me, but I think Michael’s sentiment is correct.
Thursday, February 10, 2011
Jason Gorman has just written a piece in defense of Software Craftsmanship that highlights how very dependent our world has become on software. He offers Gorman’s Law Of Software-Dependent Business Evolution:
Software-dependent businesses can only evolve as fast as their ability to write and evolve their software allows them to.
I think this is not only true, but an incredible opportunity for businesses that understand that. Let’s face it: most businesses spend an awful lot of time for a very meager increase in systems capability. Companies that do better than average can shoot to the top. Look at the spectacular successes of some of the relatively young internet companies, for examples. (Continued)
Monday, January 17, 2011
Dan North says that programming is a trade, and not a craft. I agree with him that it’s a trade, like plumbing and wiring. I’ve already disagreed with his definition of craft. I’d say that programming is a craft only when it’s done well. I’d also say that plumbing and wiring are crafts when done well. Rather than a definition, how about a couple examples to illustrate the point? (Continued)
Saturday, January 15, 2011
Dan North has created a bit of a stir with his declaration that programming is not a craft. Liz Keogh has agreed with him. The funny thing is that most of what they have to say is not about programming, but about the Manifesto for Software Craftsmanship. Well, writing is a craft, also, and I’ll agree with Dan that this manifesto is not “a call-to-arms, feisty, opinionated, brash and everything that a good manifesto should be.” It never grabbed me the way the Agile Manifesto did. Dave Hoover has taken this challenge as a call to improve the software craftsmanship manifesto.
I didn’t “sign” the Manifesto for Software Craftsmanship because I thought it was particularly well written, though. I signed it because I support the intent (as I perceive it, and which Ade Oshineye defends) behind that manifesto. Writing software is a craft, and there are far too many people who don’t treat it that way. (Continued)