ntschutta.com

As I mentioned yesterday, it’s time to clean out the old inbox of all the bits and pieces that have been stacking up. These aren’t in any particular order and they’d all justify a full write-up but I’d rather get them out there than have them stagnate in the email bucket. Enjoy!

First off, I’m on a bit of a Seth Godin kick. Here is a short riff titled What smart bosses know about people who read blogs. Maybe I’m wrong for being somewhat amazed at how many folks in this industry don’t read blogs - but at least I’m not alone. Eric Sink covers this point in his post Baptists and Boundaries where he asserts (correctly) that most software engineers don’t read blogs. Ask yourself: what kind of people do you want on your staff? Those that, when the day is done, got home and watch the latest in reality television or those that are passionate enough to crack a book? Sadly, most managers want Sheepwalkers.

Some of this, I suspect, is a fear of failure and it’s clear that most people would rather fail conservatively than succeed in a radical manner (I know I’m quoting someone but I can’t seem to find the attribution, shout if you know but for now, take a look at this excerpt from Alistair Cockburn). Of course what it means to fail is a very fluid concept that Seth touches on in The Tyranny of Opportunity Cost.

Let’s get back to that passion bit. Kathy Sierra has a great post entitled Don’t ask employees to be passionate about the company! Amen. I know why C-level types are such cheerleaders but I’m always surprised when people wonder why the rank and file aren’t.

So these last two pieces aren’t related at all to the previous ones (hey, this is a tab clearing exercise!) but they’re still very interesting. James Duncan Davidson comments on the lack of Java on the iPhone but what really caught my attention was this quote:

For me, having Java was really important. But after I left Sun and talked to more end-users, I realized that as an end-user, the technology used to create something is not important. The important part is the result.

Couldn’t have said it better myself. Ryan sent me this link to a jQuery plugin for Taconite. Very cool stuff!

Last but certainly not least, Tim Bray has a very interesting post titled Comparing Frameworks. The moral of the story - you can’t really say Java is “better” than Rails without defining what you mean by better. What do you care about more? Notice where he ranks the options in regards to developer speed and maintainability. Last I checked, most of our projects spend the *vast* majority of their life in maintenance mode and I don’t think I know too many customers that want their projects later than sooner. Anyway, good read.

Whew, that helps Looks like most people here in the big Minnie will be spending significant portions of today just digging out from the snow we got/are still getting. Oh well, this *is* Minnesota after all. I hope you’re reading this somewhere warm and dry!

The other day I gave a presentation with a set of links in it and when I mentioned that to my friend Charles (no, not that one) he said post them to the blog. So, let it never be said I don’t listen to my constituents!

First and foremost is an interview with Mary and Tom Poppendieck over on InfoQ. By the way, *great* content Floyd - if you haven’t been keeping track of the latest offering from Mr. Marinescu, you really should. I also posted a couple of articles on multitasking, something that I’ve commented on in Quick is Slow and You Have 11 Minutes. I pointed to two posts from Kathy Sierra: Your brain on multitasking and Multitasking makes us stupid? Along the same vein is an oldie but goodie from Joel on Software: Human Task Switches Considered Harmful. I’ve said it before and I’ll say it again - multitasking is a myth. People seem to harbor this insane notion that they can juggle half a dozen high priority tasks and do justice to them all…sorry, it’s not possible. But continue to believe that. Really.

Anyway, from the look of my inbox I’m going to have to do a deck clearer post…there’s been a lot of great articles out there that I’ve been meaning to comment on but have lacked sufficient time (something that I’ll have in even shorter supply in coming weeks!) If you’re getting the snow we are here, I hope you don’t have to drive anywhere this weekend…

We’ve all seen it. The shiny new system obviously won’t solve the problem it was meant to yet the funding continues - in some cases it’s even increased in a desperate effort to right the ship. Many excuses are offered but my personal favorite is the “we’ve already spent so much money - we can’t stop now.” As if throwing good money after bad is somehow a virtue.

I don’t know about you, but I think it’s pretty neat when two radically different bloggers comment on the same idea from different perspectives. Don’t get me wrong, I expected a lot of commentary on the new iPhone (yes, I want one) but last week both Ron Jeffries and the Freakonomics folks struck the same cord: staying the course. Inspired by recent events in Iraq strategy, Stephen Dubner compares Barack Obama’s recent comments at a Senate hearing to behavioral economics and the sunk cost fallacy. Jeffries goes a step further offering an explanation as to why leaders often prefer to stay the course:

“Staying the course gives you a chance to be a winner, and leaves you no worse off than any other action, which guarantees you will be a loser.”

Of course there is another reason why many managers can’t bear to kill a project - that would be admitting they were wrong about something. When finally backed into a corner (or presented with overwhelming evidence) they are more likely to practice a little revisionist history than concede they were ever mistaken about a project. Maybe more projects need a Zed Shaw to do a little analysis! It may not be pleasant, but more often than not, the best outcome for a project can be an early death.

Back at dear old SJU, John Gagliardi (recent inductee to the College Football Hall of Fame) was fond of saying “speed kills.” Of course this was in relation to quick footed running backs or wide receivers but the adage works in other contexts as well. As I mentioned earlier, Uncle Bob has been getting into the Ruby space and today he posted a very interesting comparison of the speed of an algorithm written in Java, C++, and Ruby. While Ruby code is relatively slow (and the C++ wasn’t highly optimized) there’s more to this game than raw processing speed.

I’m not saying we should write slow code - far from it. But, there are other considerations such as developer productivity and long term maintenance costs. While there certainly are some applications that absolutely *must* run full bore, I suspect quite a few businesses would take a moderately slower application if it meant their development staff could deliver working code faster. And I can’t second this notion fast enough:

I’d rather have simple, clean, maintainable code over even 1.5 orders of magnitude in many cases.

Amen.

Michael Mahemoff picked up on my recent ramblings about functional specs and adds his own 5 cents (in my mind, his thoughts are worth more than just a couple of pennies). I agree with Michael with regards to the dichotomy - like most things in life, docu needs exist on a continuum. If I’m just writing a simple little app for my own use, I probably won’t write much of anything beyond the code but if I’m reworking the software that keeps planes in the air, well, chances are I’ll need to jot a few things down!

While needs vary, as Michael says, it’s quite difficult to nail down software requirements down with any degree of accuracy.

The problem here, of course, is that Definitive-style docs require an almost impossible task of pinning down requirements, and furthermore, fixing requirements runs counter to the modern organisation’s goal of being agile.

I’m not sure why companies continue to try and use waterfall like methodologies when agile appears to be the only approach that really works. The idea that process can somehow replace people is as old as the Model T. But then when was the last time you drove one of those to the office?

The real solution doesn’t lie with more process or templates - it rests with better people. I went to a small liberal arts school in central Minnesota. Beyond my studies in 0s and 1s, I took quite a few courses from the outside the sciences, considerably more than I was “required” to take to fulfill my core credits. That was fine with me, my interests were diverse but it always struck me as odd that science folk were required to take far more humanities stuff than the non-science types were required to take in our disciplines. My point?

There’s obviously no one solution, but one essential ingredient comes from multi-talented people.

In today’s marketplace, we need more geeks with customer affinity (and fewer that dig plumbing)…but we also need customers with some appreciation for technology. But then that’s just my two cents.

Depending on who you believe, functional specs are either an absolute must or something to be avoided like the plague. While I vacillate on the necessity of written docu, if pressed I trend towards the 37signals approach - the code never lies (misleads, sure) and iterating code tends to provide better answers anyway. That said, there have been occasions where I *really* would have liked something more concrete than “it has to be like the old system…only better” or “the requirements are whatever I say they are”. While I’ll concede the need to write something down, I’ve seen many examples that go a bit, ah, overboard when it comes to specs. Seriously, if it needs a table of contents and an index, it’s time to pare it down a bit.

The struggle comes down to purpose: why do we write functional specs? Some companies believe they should be the complete conveyance between customers and developers - when you get there, you’re in trouble. By the time you’ve finished writing down every possibility (and sat through many, many mind numbing meetings), chances are the business has changed three or four times obviating all of your hard work.

So the question is, what should a requirements document provide? Agile mentor Venkat Subramaniam nails this issue right on the head - instead of trying to map every fork, provide enough depth to help the developer explore the issues.

Rather than providing answer to all my questions, I would like for it to help me ask the right questions when I am ready to delve into the implementation.

A great requirements document helps me not with right answers, but with right questions.

Keep this in mind next time you sit down to write a spec - it should aide communication, not supplant it. Help your devs ask the right questions, don’t try and answer every single one.

I must be on a bit of an Andy Hunt jag here… A couple of weeks ago he posted this link to Only the Adaptable Will Survive Change. In some organizations, change is like the proverbial third rail - touch it and someone is going to get hurt. Some people think change somehow invalidates what was done before but that’s just not true; making adjustments is a healthy activity. Anyway, there are a few great quotes from the article that I’d like to call out:

developing software is such a complex activity, anything substantive that you leave until later won’t happen, won’t happen well, or will grow worse and fester until it becomes unmanageable. A certain kind of friction increases, and things get harder to fix and harder to change. As with any friction, the only way to fight it effectively is to continually inject a little energy into the system.

How many projects have started with the ideal of testing only to have management say “we don’t have time” shortly after the project gets underway? Or my favorite “just hack that change in, we’ll go back and clean it up after that important demo.” Yeah right. Technical debt accumulates - you either pay it off over time or eventually you are forced to refinance. It’s very tempting to just let it ride, especially if things seem to be working well, but eventually you’re going to have to send a check to the bank (and the dollar amount only gets larger). We can’t let the enormity of the problems intimidate us either, a little bit each day and we’ll get to where we need to be. If we focus on the size of the problem instead of just doing something we’ll never accomplish anything. Agile methods fundamentally get this idea. Tests are written everyday, code is refactored everyday, customers are shaping the product everyday. To use an analogy, it’s a heck of a lot easier to maintain a healthy weight than it is to lose 30 pounds.

Tempting as it may be for some, it’s important to realize that agile isn’t the same as crisis management.

Crisis management occurs when problems are left to fester until they become so large that you have to drop everything else you’re doing to respond to the crisis immediately. This causes secondary crises, so now you have a vicious cycle of never-ending crisis and panic. That’s precisely what you want to avoid by adopting an agile approach.

I’ve been in “fire fighting” style organizations and it really isn’t much fun. You never get a chance to act strategically, you’re forced into tactical solutions. The pressure to just “get any fix in” causes the code to deteriorate meaning the next change will be even harder than it has to be. Quick and dirty becomes the mantra and while some congratulate themselves on being responsive, most everyone realizes there is a price to be paid for that speed.

Change isn’t limited to code though - everything we do needs to evolve as well.

Agile development recognizes the importance of pragmatism, and seeks to adjust everything—the schedule, the design, the features—based on what is really happening. It’s about facing reality and dealing with it, not hiding behind an IDE, PowerPoint presentation or a Gantt chart.

Just because we did something a certain way two years ago doesn’t mean we should still do it that way today. Heck, when Java first came out, we used text editors and the command line, today we use full featured IDEs. That doesn’t mean we were somehow *wrong* 10 years ago. Don’t forget, for thousands of years we thought the world was flat too.

As hard as it can be to change, not doing so is a recipe for disaster.

Sticking to any plan or technique that is no longer appropriate is a guaranteed way to fail. Both the dodo bird and the buggy whip manufacturers learned this lesson the hard way.

It’s important to realize that modifying your approach isn’t an admission of failure - in reality it’s the mature reaction to the world around you. It may not be easy, but the consequences of inaction are far worse than any pain the change may cause.