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. 😉

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…

Why Your Project Schedule Is No Good – And How To Fix It

I’ve already said my piece on estimating software projects, so now I’d like to offer a word on the flip side of estimating – scheduling a project. Estimating and scheduling are not the same. Estimating is the practice of figuring out how many man-hours of labor something will take. Scheduling is deciding when those man-hours of labor will take place.

For purposes of this article, suppose we’re planning a project for a 3-person team. We’ve estimated the project at about 3000 hours, which is roughly the equivalent of 6 work-months for a 3-person team.

Many folks would say “Great! Today is February 23, so 6 months means we’ll be ready to implement around August 23! Let’s get started!” and then be bitterly disappointed when August 23 rolls around and they find themselves with a late project and an angry client.

The problem is in the way most people schedule projects. They give dates that haven’t been thought out very well in order to avoid upsetting the client, but the client ends up upset anyway because the project goes off track. I prefer to make my clients upset at the START of the project, that way I know exactly how much time I have to win them back over – the length of the project (that was a joke). Also, upset clients tend to think of really creative reasons to not make their delivery payment, and that’s bad for cash flow. We’re supposed to solve problems, not create more of them for ourselves and our clients.

If you’re a lead developer who’s been asked to take on some project management duties, you probably already have good estimating abilities. You just need to keep a few things in mind when you schedule the project, things that will keep you out of trouble.

1) People are supposed to take two weeks of vacation each year – that’s 10 business days.

So, if you’re planning a 6-month project, plan for each developer to be out for a week during that period.

“But, nobody ever takes vacations at my company” you protest. Do you know why nobody ever takes vacations at your company? Because nobody schedules projects correctly, and when Joe Developer wants to take a vacation, his boss says “No, we can’t afford to have you out right now, you can take your vacation when the project is over”. But then there’s another screwed-up, mis-scheduled project going on that really needs Joe’s help, so he gets assigned to that project with the promise that he’ll be allowed to take a vacation when it’s over. Lather, rinse, repeat.

Going by our example above, we’re now looking at a delivery date of August 30.

2) People are supposed to take an average of 7 sick days per year.

If you’re planning a 6-month project, plan for each developer to be out sick 3.5 days during that period. We’ll round up and call it 4.

I can hear you already – “But, people always work sick at my company”. Do you know why people work sick at your company? Because nobody schedule projects correctly, and when Joe Developer takes a sick day, upon his return he finds there’s hell to pay in the form of piles of backlogged work.

Why didn’t the work get done by someone else while Joe was out sick? Because nobody schedules projects correctly, so every developer in the company is running late and doesn’t have time to pick up the slack for an absent team member. So between the huge backlogs of work and the roundabout brow-beatings by his boss, Joe Developer soon learns that taking a sick day is more trouble than it is worth, and start coming in to work while he’s sick. Then he gets 2 other developers sick, who in turn each get 1 other developer sick. Mayhem ensues.

If you schedule things correctly, losing a guy to the flu every so often isn’t that big of a deal.

Going by our example above, we’re now looking at a due date of September 5.

3) There are 10 federal holidays per year.

If you’re planning a 6-month project, plan for each developer to be out 5 days for holidays.

I know that not everyone gets all the designated federal holidays as paid holidays, but plan for it anyway. “But we work the holidays at my company” you say. Do you know why you work holidays? Because nobody schedules projects correctly. Are you detecting a theme yet?

New due date: September 12.

4) How many personal days are employees given each year at your company?

Most places I’ve worked only give you 5, so let’s call it 2.5, rounded up to 3 per developer to cover the 6 months of work. “But my boss never OKs requests to use personal days” you say. Do you know why your boss never allows you to use your sick days? Because nobody schedules – oh, never mind; you already know what I’m going to say.

Now we’re looking at September 15.

5) Plan for disaster.

On a long project (long for me is 3 months or more, your mileage may vary) I usually build 5 buffer days into the schedule on top of everything else, to account for miscellaneous minor disasters such as jury duty, car trouble, dentist appointments, etc. If you’ve done your estimating correctly you probably won’t ever need to dip into this time, but it’s good to have it there.

This gives us a revised due date of September 22.

6) Nobody is productive for 8 hours a day. Not you, not me, not anybody.

Over the course of 6 months, you’re going to lose a lot of time to eMail, company meetings, phone calls, paperwork, and all the other non-billable, non-work-producing things that go into a typical day at the office. It’s hard to quantify exactly how much you’re losing. But for 3 people over a 6-month project, I think 2 weeks is realistic. That’s about 2 hours a day, which means your team is getting 6 productive hours out of every 8-hour work day. Believe it or not, that’s pretty good, and might even be optimistic.

With the non-productive work time factor added to our schedule, we are now looking at a realistic delivery date of October 6, which is a Friday. This presents a problem in and of itself, however.

You see, Friday deliveries are only for the stupid and desperate. Friday deliveries invite weekend phone calls and – even worse – working over the weekend to do tech support. Never deliver software on a Friday. Let’s look forward at the next business day, which is October 9. Obviously, October 9 is a Monday.

That presents another problem, though. While Friday deliveries are only for the stupid and desperate, Monday deliveries are the domain of a very special kind of cluelessness. There are a few reasons for this. Mondays are the #1 day for people to come in late or not at all, so if you have problem on-site and need to call the office to get help from a co-worker, you might be in for a rude surprise. If you have to travel any significant distance in order to be at your client’s office to do the implementation, a Monday delivery means you’re on a plane Sunday night – and flying on the weekend stinks. You should be with your family and friends on the weekends, not waiting in line at the airport, flying in a crowded coach-class seat and then checking into the No-Tell Motel (because your boss is too cheap to let you stay at Holliday Inn) in a futile attempt to catch some shuteye in a stange bed with freeway noise coming in your window, all in the hopes of being well-rested and sharp come Monday morning when you have to do the install.

No, thanks!

Plus, I personally guarantee that if you schedule a Monday delivery, someone on your team will sneak in “just one little change” to the code on Friday afternoon, which will break the application in some subtle way that doesn’t get detected before you burn the CD.

Pop quiz: when will the broken code be discovered? a) before you get to the client site, or b) after you get to the client site, when the VP (who also happens to be the guy who authorizes the delivery payment) is looking over your shoulder as you fire up the application for the first time and are confronted with a error message that is as cryptic as it is terrifying?

Again, no thanks.

We’ll deliver on Tuesday instead, so the implementation team can spend Monday travelling or doing test installations juuuuust to be sure everything works.

So, our extra-special, well-thought-out, ultra-realistic, do-or-die delivery date for this project is…October 10!

October 10 is more than a month past August 23. In fact, it’s about 6 weeks past August 23. I know what you’re thinking: “There’s no way people are routinely mis-scheduling projects to the tune of a full 6 weeks!”

Isn’t there?

But let’s be honest here – how many of you have been on a project where an unrealistic schedule was handed down from management, and the actual completion date ended up being over a month later, if not more? I’ve been there. Several times. Every developer I know has been there at least once. Hell, I know developers who worked 16 hour days from the start and STILL didn’t make the original delivery date (although I suspect that the 16-hour days were as much to blame for the missed delivery as the schedule was, I’ll let that go for now. Another day, another article, I promise).

Now, those of you who are both bold and cynical might be tempted to point out that in a competitive bidding situation, if you say you can deliver on October 10 and the other dev shop says they can deliver on August 23, the other shop is going to get the business because the client wants their delivery date to be met. This is not necessarily so. You need to understand 2 things:

1) The other shop can’t deliver on August 23 either.
2) The client knows this.

If the other dev shop gets the business anyway, you don’t want that client. In fact, the client should not want that dev shop, either. There is an interesting game that goes on when negotiating a project, an almost unspoken agreement to not talk about real dates or real numbers, but rather to figure out which dev shop is willing to say “yes” more easily. I submit that clients who willingly play this game should be fired, and that developers who willingly play this game are unprofessional.

How many times have you been asked “so how much would that cost?” or “so how long would that take?” by a client or prospective client, only to be pressured when you reply that you need some time to figure it out? By and large, when you are asked such questions, the questioner is not looking for a real number, he’s looking for a palatable number. He’s gauging your willingness to play ball, your eagerness to please. It’s a spine check. Sadly, passing the spine check often means not getting the project. The business world is filled to overflowing with business owners, managers and purchasers who prefer a yes man to a thoughtful, competent professional. That’s a hard thing to accept, but it is often true.

As the saying goes, don’t be that guy! Yes, you should be eager to please your client. Yes, you should make yourself manageable. Yes, you should be looking for ways to make things work. But you are the expert in what you do, not your client. When you knowingly agree to do things that will not work, or (even worse) that have the potential to damage the client’s business plans, you are not behaving like a professional. In these cases, you have an obligation to say no, even if it means losing the work.

As I have said in the past, I’m not suggesting anything you don’t already know. But I am suggesting things that you don’t already do. I hear from people every day who complain of issues that boil down to scheduling for political reasons rather than for engineering needs. I’ve lost projects because I wasn’t able to tell the client that “yes, the cancer-curing software you asked for can be ready in three weeks, from concept to completion”. But you know what? I also missed my son’s first words and first steps because I was at the office, working late in a desperate attempt to make my managers B.S. schedule work somehow.

Now that I run a company, I don’t have this problem because I’m the one being a stickler for good scheduling. But thinking back, I’d prefer to have been reprimanded or reassigned instead of working myself ragged over that garbage schedule.

Life happens fast. Don’t miss out on it by trying to make magic from idiocy. Schedule your projects correctly, and your career will thank you in the long run.

P.S. Yes, I’m aware that there’s an off-by-one issue with my example. That’s because it’s only an example, not an actual schedule.

Browser Oversight and Web Design

I learned a valuable lesson in the wake of launching my redesigned company site – there is more to the web than Internet Explorer and Firefox. A number of people eMailed to tell me that the site was broken in Opera.

In one of my less-enlightened moments, I thought to myself, “Opera?!?! Isn’t that one of those hippie browsers created by people who hate capitalism and that only use Macs? I specialize in Microsoft technologies, why should I worry about what a bunch of Mac users think of my site?”

Well, hit me with a clue-by-four, because not only was I wrong about who uses Opera, that browser wasn’t even on my radar screen during the redesign.

However, thanks to those sharp-eyed folks who alerted me to the problem, I massaged my stylesheet a bit and voila! My company site is now Opera-friendly.

But then I started thinking; would it matter if my site weren’t Opera-friendly? Did I just use my time wisely, fixing the site? After all, I work with small to medium businesses, and the vast majority of those people use whatever browser just so happens to be on their computer – which is IE. A growing and dedicated number is using Firefox, so having the site work in that browser is a no-brainer too. Who are these Opera folks, I wondered, and is it even worth my time to make the site work for them?

Well, duh.

I went in and had a look at my browser stats. A quick look will tell you that most of my visitors are using Firefox, the next significant contingent is using IE, and that waaaaaaaay down at the bottom are the Opera users. A less-empathetic developer might shrug at this point, conclude that the visitor sample is too small to matter, and drop the whole issue. But not me! I pushed on, taking a look at the actual numbers. Sure, Opera users are in the minority, but how minor is minor in this case?

The numbers don’t lie: 921 unique visits came from Opera browsers last month.

921. Not quite one thousand people, but close. Even if I were questioning whether or not to fix the site for Opera – I wasn’t, by this time I had already done so – what it came down to is: do I want my company to tell 1,000 visitors per month to buzz off? Sure, the nature of the web is that you can’t possibly please everyone, but am I really prepared to hand walking papers to 1,000 people every month, without even knowing who they are? Is that an effective business practice?

Again, duh.

Sure, it took a few minutes out of my day to download Opera, fiddle with my stylesheet, check the site in Opera, then re-check it in IE and FF to make sure it still worked in those, too. Sure, it took a minute to ftp the new stylesheet to my web server. And sure, there is almost ZERO chance that any client will ever tell me "I hired your company because your site works in Opera". I still think it was worth it.

This has been a nice example of the power of public feedback. It’s a great time to be participating in the web.

Get More Freelance Clients By Using Face Time & Free Stuff

Business has been great for my little custom software company.  We’re not ready to take over the world or release a product, but things are doing OK.  I’m happy.  And I’ve been pondering the means by which I’ve managed to grow the business and get more freelance clients.  Sometimes I wonder if success in any endeavor just boils down to luck, a happy accident.  But after a talk with a good friend and colleague, I think I understand what has happened.

How does any business get customers?  By advertising?  Nobody pays attention to that anymore.  By clever PR?  Sure, there’s always the odd person who will hire you because he saw that newspaper article about how you donated 100 hours of your time to build a website that takes donations to help cure those poor kids in the oncology ward of the local hospital.  But as I talk to other solo and small businesspeople, an interesting trend reveals itself:  the #1 way small freelancing firms get get more freelance clients is by utilizing the “face time and free stuff” technique.

I can hear you already – “Wha-a-a-a-t?” Just bear with me for a moment.

People like to do business with their friends.  Period.  Finito.  End of story.  Go out and ask 100 prospects if they’d rather do business with SuperMegaJumboCorp or with their poker buddy Bob.  Go ahead, ask them.  I guarantee you that if Bob is even remotely competent at doing what SuperMegaJumboCorp does, 100% of the time, the prospect will choose Bob.  Yes, he could get hit by a bus and take the project to the grave with him.  Yes, he’s only one guy and can only provide so much support.  Yes, he could get hired away.  But Bob will get the business in spite of all this, because he is the prospect’s pal. Being a friend and a known quantity is how Bob can get more freelance clients than you can.

I’ve actually had prospects tell me outright that yes, Bob has royally screwed up our database, and yes, it’s hard on our business sometimes, but we’re not going to fire him because well, we’ve known Bob a long time and he’s just a real good guy.  Competency didn’t even figure into the equation!  What can we learn from that?

When I first moved to the Central Valley, I didn’t know anybody.  Not a soul!  But here I was, with a new home to pay for and a family to feed, one of about a dozen people freshly laid off from a company that came thiiiiiiiiis close to going out of business (but later thrived and got acquired by PeopleFluent).  I had a handful of small clients, but in early 2003 nobody was hiring developers and nobody was taking on custom dev projects.  Obviously, I had to make something happen.  So what was my first move?  Did I take out a Yellow Pages ad?  Did I spend $75 to have a bunch of business cards printed up?  Did I paper the business district with flyers?  Did I go running to the Chamber of Commerce?


I sat down with a copy of the Yellow Pages and hand-wrote – yes, hand-wrote, the same way your grandmomma hand-wrote letters to your grandpappy way back when he was serving in the Big Red One – a series of personal letters to the principal of every business in town that appeared to be even remotely technology-related.  But I wasn’t asking for work.  Oh, no.  That would have been sad and small and would have gotten my letter tossed in the trash immediately.  Instead, I introduced myself, briefly summarized my industry experience, and asked about the principal.  I offered to take the principal to lunch and talk shop.  I didn’t approach anyone as a supplicant looking for a favor – I approached them as a peer looking to get to know his fellow tech industry workers.  I forgot all about my predicament and focused on striking up a few new friendships with these interesting new people I was about to meet. In short, I embarked upon a friend-building campaign.

I paid for sushi.  I paid for Tex-Mex.  I paid for American Chain Cuisine.  I visited offices.  I talked, I joked, and I listened – oh, I listened.  People really, really like to talk about themselves.  And in the process of all this, I became friendly with some people.  Friendly enough that eventually a local business owner I’d introduced myself to confided in me that she was unhappy with one of her employees and wanted me to take over his position.  I politely declined that particular bit, but soon ended up doing some other work on contract for her.  Revenue at last!  Pleased, this business owner introduced me to some friends, one of whom I really hit it off with.  I ended up doing a little bit of work with him, too.

Around the same time, two other unrelated local principals took me up on my lunch invitation and I ended up hitting it off with them as well, the result being a little but more work.  Then a sweet lady from a local charity caught wind of my presence in town and invited me to bid on a project.  I took her to coffee, talked about her project and her charity’s mission, and eventually won the bid. This was the start of me beginning to get more freelance clients.

What’s the commonality?

I got face-to-face with these folks.  I got friendly with these folks.  I shared space and time and broke bread with these folks on my own dime before I ever asked anything of them.  In most cases, I never actually asked anything – eventually they just pulled me aside and gave me the “Hey, do you know how to do X?” routine.  But why me?  Why not the 72,566,985 other guys out there with similar qualifications?  Why did I end up getting the business and not them?

Because 72,566,984 of them didn’t bother to reach out, get face-to-face, and hand over a free lunch, that’s why.

When I bid, I’m usually the most expensive bid.  My rates are reportedly higher than most for the local area.  I’m neither handsome nor charming enough to leave people starry-eyed long enough for me to conk them over the head and lift their wallet.  But by golly, I seem to do an alright job of making a new friend over a good meal.  And that appears to be enough to put me in the running for most projects I want to be involved with.  Everyone likes face time – a real conversation with a  real human being.  Everyone also likes free stuff – a real, honest-to-goodness, no-obligation freebie, like lunch at your choice of restaurant or your favorite flavored latte delivered to your office, just to say hello.  And the best part is, everyone can do this to get more freelance clients.

Just take yourself back to the schoolyard for a moment, when you were young and open and not conditioned to fear rejection.  What did you do back then to make a new friend? “Hi, you wanna play with me?” or “Here, want half of my sandwich?” were both perfectly acceptable ways of introducing yourself as a kid – unless the sandwich you were offering contained baloney.  Thankfully, the adult world isn’t THAT different.  Baloney still doesn’t fly, but a simple hello and a lunch invitation can work wonders for making new friends.  And if you take care of getting out into the community and making friends with people, the business will be more likely to come.  Sure, it’s not going to come from every person you meet, nor is every new person you meet going to become a friend.

Even so, you’ll certainly become friendly with many people, have a lot of interesting conversations, and pump a lot of “you” presence into the collective mind of the local marketplace.  Eventually, when there’s enough “you” in the mindspace of the market, the pressure will cause something to pop, just like a closed system that’s been pushed beyond capacity.  And that pop can end up putting dollars in your pocket once you start to get more freelance clients.

Face time.  Free stuff.  Get out in front of people.  Open up.  Make some friends.  Don’t ask for business, just get out there and befriend people – become a known part of the local business community.  Give somebody lunch, or a t-shirt, or a free hour of your time to fix a problem, or shut your yap and listen to someone tell you about himself.

It takes time for this to work.  But for truly small businesses – especially those who are not located in prospect-rich environments – face time and free stuff is a great way to operate. If you’re not having conversations with new people regularly, you may be missing out on a lot of otherwise-hidden opportunities. This alone won’t build a business for you, but it pays to make this habit a part of your overall strategy to get more freelance clients.