Wednesday, May 31, 2006
Reading List: Eric Sink on the Business of Software
I'm currently about halfway into Eric Sink's book. So far, so good. I remember most of this from his MSDN column, but it sure is nice to have it sitting on my desk or in my briefcase. In fact, it's going to be my official Road Book when I fly to the East Coast this Friday. Eric's got this business nailed down, there's no doubt. Plus, he's very good at communicating non-geek concepts to geeks, seeing as he had to learn all this stuff himself (and sometimes the hard way). So if you haven't read it, I definitely suggest you pick up a copy. Note that this is not a paid solicitation, it's just my opinion.
The reading is definitely piling up. Here's what I have on deck, waiting to be read:
- Purple Cow
- The Effective Executive
- The Ultimate Sales Letter (revised edition)
- Never Eat Alone
- Professional ASP.NET 2.0
- Outfoxing the Small Business Owner
- DOM Scripting
This is just what I have stacked up at the office. I think I have a couple of unread books tucked away in my bedroom, too. Arrgh.
Friday, May 26, 2006
Digital Construction, Up-Front Design and Happy Clients
I know that "no specs" is very big right now, with high-profile designers insisting that you don't need to do any kind of documenting or specs, that you just need to make a few sketches and then start writing HTML prototypes, re-writing it until the customer likes it. This sounds suspiciously like the code-and-fix model, which we all know is garbage. Even worse, it sounds like undisciplined, hippy-dippy, egocentric, "I am an artiste" thinking. In fact, I dare say that it is non-design. For God's sake, people, we're in a pseudo-engineering profession. Act like it. Plan your work ahead of time, at least the important parts of it.
Also, I'm not sure where people find clients who are OK with having no idea what they're paying you to produce until you finally nail it on the 155th HTML re-write. "We're being iterative". No, you're being lame and wasteful. Clients LIKE to have some idea of what is being built before you start working. Clients LIKE to have some idea of how much time it will take before the project starts. Clients LIKE to have some idea of how much it is going to cost before the first invoice arrives. If you simply start writing code and re-write it until the client likes it, there is no way on God's green earth that you can reliably provide accurate answers to the questions of What/How Long/How Much.
That said, you can't plan for and spec out everything, either. If you do that you'll never get any actual work done. You also don't leave any slack in the project to allow for change, and allowing for change is good (that's the one thing that the hippy-dippy non-designers are right about). The trick, the real trick, is to follow the 80/20 rule and nail down the most critical 20% as best you can before starting.
I know that you're all going to scream that this is an awful analogy, but think about buying a house. The builder is going to provide you with a floor plan, some elevation renderings, and maybe even some material swatches. The builder is NOT going to say "wood is cheap, so we'll just frame it up and let you request changes until we have it the way you like it". That's wasteful of everyone's time. And it is still wasteful even if you are "only" writing HTML mock-ups, creating screens in VB, or coding interfaces in C#. Don't start writing code until you know (mostly) what it is you need to write.
Yes, I realize that writing software applications and creating websites is not the same as building a house. However, I believe that this digital construction industry of ours can - and should - learn from the physical construction industry. We need to get over ourselves and admit that our profession is not so much of a unique snowflake that we can't learn from our analog counterpart.
This is something that I have experimented with myself in recent months. I don't do lavish mock ups, but I do produce simple "floor plans" for clients when I take on a new web site or application project. All it takes is a flow chart, a layout diagram showing where the controls are going to be placed on each page or screen, and some notes right there on the layout diagram. Add in a page per screen outlining whatever business rules apply to the task the screen helps to accomplish, and a few more pages describing the context and any additional particulars regarding the process we're trying to automate or streamline. Heck, one time I went so far as to print the diagrams out like blueprints. The client loved it. We scribbled on the diagrams, then I made the changes in Visio and re-printed. We did this until we had hashed out all the spots that didn't look right. The client was pleased to feel like they had the most critical things hashed out before construction was in full swing, and I had a clear blueprint to build from that actually reflected what the client wanted. No guesswork. No rework. We made a few more changes as we went along, because you can't predict everything, but we more than covered the critical 20% and it made things go so much more smoothly than it would have gone if I just jumped in and started writing code.
It doesn't take much to come up with a good development blueprint to help steer the developers and some good client-facing materials that let the client know what they're getting into BEFORE construction actually begins. You don't have to produce NASA-level documentation, but you do need something to steer by and to make sure the client understands what is about to be done. I often hear developers and designers suggest the ludicrous idea of a one-page story for an application. Think about how crazy this is. A one-page story is not enough for a whole application, even if it's a tight and focused application with few features. There is no way that a client is going to really understand what you're building from a one-page story.
Now, bear in mind that although I am an advocate of designing up front, I am not an advocate of letting that design be sacred from its very first draft. can you change the design once the client takes a look at it? Hell yes. SHOULD you change it? Probably. It's rare to hit a home run on the first try, and the documentation is not meant to appease people, it's meant to make sure they understand what's going on so they can question it and change it if needed, BEFORE it's actually been built. Designing up front lets you catch a lot of mistakes before they are made. Paper is cheap. Visio is cheap. Take advantage of it.
I've heard this referred to as Big Design Up Front, but it's not really big, not if you do it right. It's more like Lean Design Up Front. And trust me, it is infinitely better than No Design Up Front.
Thursday, May 25, 2006
Mixed Martial Arts Fans, Rejoice: IFL Is Here
This blog post is unusual in that it addresses a non-business personal interest of mine, and in that it is a blatant bit of promotion for one of my clients. There won't be many of these, I promise, so just deal with this one. ;)
As a long-time fan of Mixed Martial Arts, I was very excited and honored to bring the International Fight League aboard as one of my company's clients (as the world's first Mixed Martial Arts league, they're taking a team approach to MMA that nobody has tried before. Think collegiate wrestling meet, with 5-man teams, but with world-class kickboxers, jiu-jitsu artists, wrestlers, etc. It's great stuff).
During the course of our web project with them, the folks running the show at IFL have proven to be solid, courteous, competent and easy to work with. That is why I feel OK about promoting them so openly; I'm basically a big fan of theirs. None of this is paid promotion, it's just a fanboy gushing about his favorite sport.
On June 3rd in Atlantic City, IFL will be putting on a Mixed Martial Arts show; the 2006 Legends Championship. This show is the finals of a tournament that started on 4-29, when 4 teams of fighters faced off, with the 2 winning teams moving on to the finals. Well, the finals are upon us in just a couple of weeks and I want to implore any readers who are MMA fans to check it out. If you are able to attend in person, the show is at the Trump Taj Mahal in Atlantic City, NJ. There is a Ticketmaster link on IFL's site.
If you can't attend in person, you can check out the second round of the tournament on television by watching FSN this Sunday (check for local times). Then, you can catch the finals on FSN on June 4.
Again, I'm not a big fan of blatantly promotional blog posts, but this organization, this sport, and these athletes - they all deserve it. I will now return to writing a boring, non-promotional software blog. ;)
Tuesday, May 16, 2006
Software and Surgery
I was watching television last night when I had some random thoughts about my work. As you probably know from reading this blog, I run a small software company that specializes in rescuing projects that involved broken or underperforming software applications.
Today's glut of hospital-based television shows often depict some surgeon valiantly trying to save a life, working for 12 hours at a time in a sterile, high-tech facility that includes a viewing gallery and CD system playing Mozart as the nurses and other assistants stand by to hand the surgeon tools, dap his brow, and provide enough suction to keep the work area clear.
Alternately, you have the style of surgery depicted on M.A.S.H. - the patient comes in all banged up, you zip him open, do the minimum amount of work required to repair the damage, and send him out. All this while running the hospital 3 nurses short, with a rapidly diminishing supply of blood and mortar shells going off near the camp's perimeter, causing the lights to dim and flicker as the surgeon's work. This is not-so-affectionately referred to as "meatball surgery".
Being in the business of remediating software applications, I'd like to be able to say that it's a lot like the first example, the clean, high-tech, sterile, orderly example. But it's not. In fact, it's not even close. Remediation is much more like M.A.S.H. - by the time the patient gets to your operating table, there is no time and no resource allocation to speak of - you've got to get in, work by your wits, and get out. All this with mortar shells going off and lights flickering. One of my consulting colleagues even jokingly refers to me as the Hawkeye Pierce of software development. I can only argue against that to a limited extent.
The term software remediation may sound as though I'm trying to put my own clever spin on the term "refactoring". I'm not. Think of it this way - if refactoring is micro, remediation is macro. Remediation takes you all the way back to the original assumptions that went into making the design choices that led to the application being in a state that requires remediation. The word remediate literally means "to repair an oversight" or "repair a deficiency". So, it bears a decent resemblance to what you see going on in television's medical dramas - patient has a problem, surgeon must fix it, add drama, stir well, cook for 30 minutes, and you're done.
I once read a tale of a fellow who had a tumor in his neck. It was thought to be a simple cut and close job, but once the surgeon went in he discovered that the tumor had strands wrapped around every major structure in the patients' neck. What began as a simple excision turned into a 12-hour marathon of carefully cutting around healthy structures to remove the cancer in bits and pieces. You have to feel bad for that doctor - he probably had his day all planned out, and some pesky tumor threw a monkey wrench into his plans.
That reminds me of many of the projects my company takes on - more often than not, taking an application offline is absolutely not an option. We frequently have to redesign, refactor and retest in a live application because time and budgetary constraints dictate that creating a test environment is out of the question. Sometimes clients are literally losing money by the minute because of their broken software tools. On top of that, we are frequently working with clients that are hostile to developers in general because the guy that delivered the poorly-performing app we are fixing did so after going way over budget and way over the deadline, and as far as the client is concerned developers as a lot are bastards.
Obviously, this is not ideal. But it is often how the world works. Fixing broken software in the wild is a lot more like the resource-poor grit of M.A.S.H. than the yuppified plenty of Chicago Hope.
I'm doing my best to move my company away from this kind of remediation work. Too much stress, too little reward. To stick with the medical analogy, if I could go from M.A.S.H.-style remediation to, say, House-style remediation on a regular basis, that would be great. Dr. House at least has a little bit of time to whiteboard the problem before everything hits the fan and he has to do something, (even if it is wrong) because doing nothing would surely result in disaster. Most of the remediation projects I bring in now require us to hit the ground running.
In truth, I've had a few of those, where the application in question was broken but still usable (barely). It was nice. I rallied the team, spelled out the problems, reviewed some code, came up with a list of bottlenecks and problem points and formulated a plan of attack. I like that. Not totally planned, but not totally improvised either. A happy medium. House-style remediation sounds nice, I'll have to try to get more of those projects. And truth be told, my demeanor is closer to Dr. House than Dr. Pierce. Alan Alda's portrayal of Hawkeye Pierce is just so damned earnest, even at his worst - I am much more of an arrogant jackass.
Long story short, emergency medicine-style software projects no longer have any appeal for me. If I'm going to commit my team to a remediation project, it can't be a total disaster the moment we walk in the door. I realize that I'm probably going to get a flood of email now from people asking me to look at their total wreck of a project, but please - don't send those eMails. I don't want those projects, and would have to be offered a lot of money to take another one on. In fact, I am tempted to remove the Software Remediation section from my site completely and offer it only as a "stealth service" to those that know to ask.
Paging Dr. House...
