ntschutta.com

Andy Hunt recently posted a great piece: Stage 0: Not Ready For Agile. He was all set to give a talk at a company until, well, someone discovered he was coming. Turns out the manager that contacted Andy hadn’t followed the non-existent process and instead of congratulating him or her on bringing in a well known speaker, they decided it’d be better if it could never happen again.

As stunned as I was by this, I’m not surprised. Talk is cheap - it’s easy to say you want to be (or are) agile but the proof is in the pudding. You can say you value collaboration but when there are three levels of indirection between developers and end users, that statement echos hollow.

Culture plays a huge role in how we build software; Andy lists several traits that indicate you might not quite be up to the challenge of agile. Some are fixed more readily then others but if your culture won’t support it, you’ve got your work cut out for you. Unfortunately, cultural issues don’t respond to technical solutions as Reg Braithwaite says so well with this quote:

“Cultural problems cannot be solved with technology. If you are an advocate for change, ask yourself what sort of cultural change is needed, not what sort of technical problems need to be solved.”

Changing culture is hard, but for many organizations, it’s the critical first step towards better software.

It shouldn’t be a big surprise that I prefer low ceremony agile processes to their heavyweight waterfall brethren. While I’m certainly not anti-process, I’ve spent way too much time in meetings defining how we were going to write software. Recently I wondered, do other industries spend so much time on mundane details like templates for issue logs? Perhaps they do, but I doubt the architects of the new 35W bridge spent a lot of time discussing the how they would document the plans for the new roadway.

Most companies I’ve worked for spend an awful lot of time and money on process. Much as no serious enterprise would ever consider deploying SAP or PeopleSoft without a hefty does customization, every organization wouldn’t dare to use an off the shelf process. No, it’s better if a group of people spend months coming up with the perfect approach and a set of presentations that would make Tufte weep. Despite a lot of pats on the back, I’ve yet to see this effort lead to any significant business value, yet it is a persistent part of the environments I’ve worked in.

It seems to me that most companies focus on process for one of three interrelated reasons. First off, there are a number of people in technology that, well, aren’t very technical. Some of these folks *used* to be, but many just bluffed their way into higher paying roles and well, they need things to work on. Of course not everyone needs to spend their free time brushing up on the finer points of the closures in Java, but last I checked templates don’t compile their way into working software.

Second, software projects have a nasty tendency to fail and to combat this fact, most organizations want greater control over the work. To accomplish this goal, they invent more and more process, more gates, more checkpoints. Of course it doesn’t really work that way, and the tighter they grip, the worse things get (hmm, sounds like a Star Wars quote to me.)

Project failure brings us to reason number three: plausible deniability. If (or is it when?) a project isn’t everything it can be, we can always point the finger at the process as either a point of blame (if only the process had a few more gates…) or as an example of success (as in: we’ve got a great process now…) Following the corporate standard also gives managers et al an easy out: yeah, the project failed, but we followed the all mighty process.

Don’t get me wrong, heroic software development isn’t good either. I’ve worked in manners best described as fire fighting and frankly that’s just too much stress for me (though some people I know absolutely thrive on that rush.) Like so many things, process lives on a continuum. At one end, we have absolutely nothing - hack and code, cowboy coding, whatever you want to call it. On the other end, we’ve got extremely heavyweight command and control approaches that attempt to plot out when every developer will use the bathroom.

Truth is often found between extremes and we should seek a balance. Do what’s right for your project though I’ll always favor the less is more camp. And before you spend the next few months creating the perfect process see if something off the shelf will work. Better yet, try some stuff and see what works for you - repeatedly ask yourself these two questions: what worked and what didn’t; do more of the first and less of the second and you might just find yourself on a successful project.

Surfing my blog reader the other day, I couldn’t help but react to the news about Microsoft bringing ads to the Zune. Boy, that ought to *really* help sales. Reg Braithwaite has commented on this already but I’ve really got to wonder how long it’ll take companies to figure out that putting the customer first works. I think Reg hits on it - we aren’t the target market here, shareholders or marketing departments are. Clearly the music industry doesn’t get it but anyone want to wager on the likelihood of ads on an iPod? Only one US air carrier posted a profit in the first quarter and they consider themselves first and foremost a customer service organization. Huh. Wonder if there’s a connect there? Nah, couldn’t be.

Like pretty much any office with more than 3 people, we struggle with the ephemeral concept of knowledge management. Now, this takes the guise of everything from cultural lore to more basic issues like where is the latest version of the FooBaz document but the moral of the story is simple: we’re still trying to find the right approach. We have a corporate product that hardly anyone uses because it’s slow, the search is horrid, and it has very rigid ideas around who can post what where.

Recently, a number of teams have started to use a different product, one they are finding to be far more useful then the corporate standard. Though it isn’t officially supported, it’s gaining quite a bit of traction throughout the organization. Imagine my surprise when an IS wide email goes out saying, in essence, that everyone should STOP using the product that’s working and contact the head of the crappy product team immediately so they can “migrate you over” to the “standard.” In other words, cease doing the thing that’s working, not “wow, we’ll fast track the adoption of this new tool since it’s serving such a vital need.” Makes perfect sense.

As I was reading the email, I thought of St. John’s (Go Johnnies!). Anyway, around the time my father was in school, they built the tundra dorms - named as such for the large open space between the bulk of campus and the dorms. Anyway, when they built the tundra dorms, they didn’t put in sidewalks right away, they waited until the students had worn paths and just paved those. Rather then guess what route residents would take, they let the property emerge. Needless to say, this approach worked pretty darn well.

The parallel here is pretty obvious - right or wrong, the “students” are wearing a path towards this new tool. Now I’m sure we can argue that the corporate standard can do “everything the new tool can do and so much more”, but the crowd has spoken. Instead of using scare tactics to keep people from using it, perhaps the bureaucracy would be better served by following the herd.

A few years back, my wife and I built a house. OK, so *we* didn’t actually swing a hammer; if you’ve ever seen me attempt a project around the casa, you know hiring the project out was the sanest course of action. This was my second go round with home construction, a process that many say they’d never repeat. But hey, I’m a glutton for punishment so in we plunged! I’d mostly walled off the entire experience in that place we put painful events like child birth and two-a-day practices, but last week one of my projects got me thinking that maybe, just maybe, there’s a comparison to me be made between house construction and building software.

Before I get started, I have to consider whether I’m on shaky ground here - many people have written pieces questioning the whole construction analogy. For starters, my friends Neal Ford and Glen Vanderburg have their takes with building bridges without engineering and bridges and software. Jack W. Reeves’ classic What Is Software Design? is a must read and Reg Braithwaite has a great post about what he admires about engineers and doctors which has this money quote:

Try this: Employ an Engineer. Ask her to slap together a bridge. The answer will be no. You cannot badger her with talk of how since You Hold The Gold, You Make The Rules. You cannot cajole her with talk of how the department needs to make its numbers, and that means getting construction done by the end of the quarter.

Considering the shared experience behind that impressive collection of wise words, I’m questioning my sanity to even think a construction analogy might fit software. But, even though I’m conflicted about the whole thing, I’m still going to share. Heck, maybe I’ll learn something in the process.

When we built our house, we spent several weeks looking at model houses, poring over floor plans, looking at carpet samples - all sorts of fun stuff. Now, with the last “home project,” during the requirements gathering phase we were just focused on the big issues: do you want a built in here? Would you like a fireplace? How about a skylight here? You know, the stuff you’ve got to get right before the foundation is set and the walls are up. At various stages, I’d get a call from the project manager (yep, that was his title, I’m feeling more confident already!) and he’d setup a time for me to come out to the site and work with one of the trades on issues like outlet placement. With my sample size of one, I expected a similar (iterative) process this go round - alas I was wrong.

You see, this builder had a different approach. They believed heavily in making all (and I mean ALL) the decisions up front (can you say BDUF?) Being a software geek, I think I do a pretty good job of thinking abstractly but needless to say, it can be quite a challenge to figure out where you want your phone jacks when all you have to go on is a 2D model of your future dwelling. I pushed back on the builder and was told they did this for a reason - they felt that if everything was on the plan, I could go on (as they put it) a four month vacation and come back to a completed house *exactly* as I intended it to be.

As much as I wanted to believe the people I was about to give a very large check to, I wasn’t convinced and as you might expect, my wife and I were on site pretty much every other day keeping track of what was going on. It was a good thing we were vigilant customers constantly running our acceptance tests. Nearly every visit revealed something that needed to be fixed, a story to be added to the backlog (or punch list in this case.) Some things were minor - a switch not controlling the proper light or a misunderstanding about what the plumbing code would allow. But others were, well, of the show stopper category. For example, despite a very clear floor plan showing where the washer and dryer were to be, the plumber decided he’d just put the washer where it was in every other house. Thank goodness we caught it early but this whole “we get it on the plan thing” certainly didn’t work in practice.

So what the heck does this have to do with software? Well, one of my projects has a customer group that thinks like my builder - they want to give us all the requirements, we give them an estimate, then they don’t talk to us until the project goes live. Obviously, this doesn’t work too well. I’m not sure why people ever thought this approach worked, heck, if we can’t get it right with houses (something we’ve been building, oh, forever) how can we possibly get close with a discipline as new as software? No, the answer is found in an agile approach where we work closely with our customers. Does that mean we need to see them for eight hours a day everyday? I sure hope not, but if they aren’t willing to commit some time to the project, how important could it actually be?

Needless to say, we’re trying to get the customers to think different, to embrace a more collaborative approach and I hope we succeed. Otherwise, I have a pretty good idea what will happen after that four month vacation.

You’d think after the hubbub over Sony’s rootkit problems of 2005, companies would know better but apparently Sears has decided that “community participation” has a very special meaning. I have no idea how any company could possibly think this was a good idea… BTW, if you’re not reading Schneier on Security you’re really missing out.

As the year comes to a close, I wanted to note a few interesting things I’ve read of late. I’m sure I could come up with a few hundred words about each but the kid is napping so I’ll keep this short and to the point. I first ran across this quote on Daring Fireball (a must read BTW) but seeing it again on Reg Braithwaite’s Raganwald spurred me to post it here:

Any sufficiently advanced incompetence is indistinguishable from malice.

Well, that explains an awful lot.

Mike Nygard had an interesting post about some of the common pathologies we see in this silly industry. I found the part about negotiating particularly fitting but if you haven’t seen budgetculture, I’d love to know where you work. My friend Ted Neward has his annual prediction piece - lots of very interesting fodder hiding in there. All I have to say is Granny Schottenwilkins has been a proud Mac user for years but I’m sure there are some Windows 98 users in Wisconsin.

Jeff Atwood’s Coding Horror reminds us that we all write shitty code. I’ve run into some amazingly arrogant developers that were convinced everything they wrote was pure gold, too bad they’re the types that generally don’t read, well, anything. Speaking of Jeff, I liked his take on registration keys though I’d point out that some companies trust their users…

Anyway, just a few good reads to finish off 2007. Happy New Year to all three of my readers!

Like any industry, ours likes to pretend that today’s problems are new and unique - it’s part of how we justify our salaries. And while the demands on what we are expected to do with technology continues to exceed the gains made with improved languages and hardware, the more things change, the more they stay the same. For example, take collaborative work environments. With today’s focus on outsourcing, far flung offices, and distributed supply chains, using technology to help distributed teams work together is a must. While some people might think this is a relatively new phenomena, in truth, Douglas Engelbart (inventor of the mouse) was working on these issues back in the early 60’s (a point Doug Crockford made in his RWE keynote). A while back, I stumbled upon this video of a presentation from Alan Kay circa 1988.

During the talk, Kay shows a video of Engelbart demonstrating some really amazing stuff. In the presentation, Engelbart works with a colleague located about 30 miles away - along with sharing the desktop, they’ve got full audio and video connectivity. Needless to say, I was pretty wowed.

Further along, you see some amazing applications developed by school children! While some of this may seem quite simple today, you have to consider when this was filmed. I’ve long been fascinated by novel ways technology is applied in the classroom - something beyond using a word processor or doing some research on the web. I have to wonder what has become of programs like those discussed in this talk. Of course now we have things like Yahoo! Teachers but still, the focus seems to be on attendance and grades not on enhanced teaching methods.

These days you can’t swing a short iron without running into some discussion of patent law and how it applies to software (or more often doesn’t apply) but I was really surprised to hear it come up in the Q&A of Kay’s talk! To paraphrase Alan, while he feels that protecting inventions is good, there is “enormous confusion between what’s an idea and what’s an invention”. He argues that there should be some protection but that it is and can be abused. A little later, he argues for more than just a technical education and as a graduate of a small liberal arts college, I was very pleased to hear him urge computer scientists to get a liberal arts background arguing that the challenge is to find the aesthetic. Frankly, I think my BA in computer science makes me a far more well rounded individual and has allowed me to perform a wider variety of duties.

Anyway, a very fascinating presentation by a giant of computing. I highly recommend you take the time to watch these; despite their age, they are still quite timely.

Despite our best efforts, many technology projects don’t succeed (and a few that do define “success” in interesting ways…) Many many words have been spilt trying to answer why failure is so common and even more describing the one true way to counter that sorry state; I’m certainly not going to add to that ink bath but maybe I can give you a heads up that will save you the pain of yet another death march. In a series of chats with various project survivors, I’ve assembled the following short list of signs that you it might be time to find something new.

• “The file extension is .java” is the first item on your code review checklist.
• You throw out a random TLA in a meeting and no one misses a beat.
• The project manager says the data model is already 95% done.
• The use of the term “code smell” is outlawed.
• Developers insist that unit testing will only slow them down.
• Estimates aren’t ranges.
• Your manager tried to send people to Waterfall 2006.
• Technologies are evaluated based on the quality of the golf course.
• The first thing the tech lead does when he downloads a piece of open source software is hack the code.
• The term “Big Bang” is thrown around liberally.
• Your project structure requires an upgrade to your toolset in order to function properly.
• The architect is babbling like the Oracle at Delphi…and everyone is nodding.
• You feel the need to build a “concrete containment building” around a part of your code base.
• Your IDE is responsible for generating nearly all your code.
• All technical questions are answered with a recap of the project history.
• End users have update access to the production database tables.
• You do something special when your page has checkbox3.

Though influenced by my own experience, any resemblance to projects real or imagined is entirely coincidental… [Shortly after writing this, I was listening to a Java Posse podcast that had a nice list of project smells.]

The last couple of days I’ve been involved in what I would essentially term a code review of some things our off shore team recently completed. To say there were some issues would be a bit of an understatement and it has certainly helped cement the need for continuous integration, frequent review, and a strong test suite. While I expected some odd use of inheritance, the empty interfaces caught my eye and I spent longer than I like explaining why YAGNI would be the team’s default position on pretty much anything. But none of that is really worthy of a blog post - that’s just run of the mill coding stuff. No, the real inspiration was this little gem:


public class Constants {
  public interface UIConstants {
    public static final String foo = "foo";
    public static final String bar = "bar";
  }
}

Now, I know some people think that interfaces are the cat’s meow for storing constants, heck, I even did it once in a past life (I was young, I needed the money) but I’ve vowed never to follow that antipattern again. Don’t just take my word for it - Joshua Bloch calls it out in his must read Effective Java (I for one can’t wait for the updated version). I’ve done my part to eradicate this erroneous use of interfaces but when I saw the code above I was floored.

Frankly, I’m a little surprised it compiles but unfortunately it does. Of course I found myself asking *why* anyone would even think to use this approach. Wait, I can hear it know “we only have one place to go to look for constants and we have namespaces too.” Um, OK, then please explain why there were a couple of other interfaces that were also called Constants and did you catch the whole antipattern comment? Furthermore, explain why you think it makes any sense at all to have an interface as a member of a class. Talk about abusing the constructs of Java.

Needless to say, we extracted those so called interfaces into real honest to goodness classes that couldn’t be instantiated. And for those of you that will complain about how painful it is to write UIConstants.foo in your code, have you heard about static imports yet? Should you go down this road though *please* don’t go overboard; as the Sun guide says:

If you overuse the static import feature, it can make your program unreadable and unmaintainable, polluting its namespace with all the static members you import. Readers of your code (including you, a few months after you wrote it) will not know which class a static member comes from.

Needless to say, it’s been an interesting few days reviewing this code - I wait with bated breath to see what next week brings.