Entries from February 2006 ↓

New Article – Timeline and Risk: How to Piss Off Your Software Developers

From my new article Timeline and Risk: How to Piss Off Your Software Developers:

“And that’s why telling someone to build higher quality software in the same amount of time is insulting, because you’re essentially telling them they’re not giving it their best effort. That they’re screwing off.

And that makes people mad.”

Read the complete article here.

Timeline and Risk: How to Piss Off Your Software Developers

Today we’re going to focus on a sentence that will make almost any developer, even a mild-mannered one, want to box up their red Swingline and head to Tahiti for early retirement.

I believe that software developers strive to do the best work they can. Most programmers will fight tooth and nail, work evenings and weekends, and scale Mt. Everest on their hands to make sure they don’t let their team down. I am, of course, speaking of teams that don’t have morale problems. While I acknowledge that they exist, they’re not the focus of this article.

In the context of a high-functioning team, some developers have the innate gift of self-motivation and strive for their best at all times. For others it’s the team dynamic that keeps their hands on the keyboard. As a developer learns to rely on his teammates and trust relationships form, they make it difficult to coast for fear of letting the group down and the thought of being dubbed the weakest link. This amalgam of competition and camaraderie is what helped companies like Google, Apple and Microsoft dominate their markets and convince their employees to work 90 hours a week and love it.

But getting back to the point: what’s the one sentence that makes software developers angry?

You might be thinking it’s the insidious:

“This bug is only reproducible on Opera v0.3 for the Commodore 64, but fix it anyway,” or the always favorite

“We don’t have a design yet, but start building something because our deadline isn’t moving”.

Nope on both counts.

This sentence I speak of is the lesser known:

“Build higher quality software in the same amount of time.”

That’s it…only ten words, fewer if you overlook some grammar rules. So why is this sentence so potent?

On its own merits, the phrase build higher quality software in the same amount of time will not incite your software developers to riot. But let’s examine the underlying message.
Irrelevant Image: Yosemite Mountains
The Triangle
Quality and speed are two of the three forces in the famous three-sided triangle of quality, speed and cost. It’s a fairly well-known business principle that you can choose two of the three sides of this triangle; anyone who tells you otherwise is trying to sell you something. As an aside, if you buy what they’re selling, send me an email ‘cuz I have some Beanie Babies I’m looking to get rid of.

There are many definitions of “quality,” but in this article I’m speaking of software that is well-designed and well-written so as to ensure high availability (high uptime) and make it easy to maintain and extend.

With that in mind, let’s look at what happens if you keep cost the same, meaning you don’t hire more developers, but want to develop higher quality software.

You could ask your developers to work more hours. This would likely work temporarily, at least, since more time usually translates into increased productivity. It’s debatable whether someone performing work as concentration-intensive as programming is able to function well after a solid 8+ hours, but I’ll give you the benefit of the doubt on this one. Even so, studies have shown that “continuing scheduled overtime has a strong negative effect on productivity.” So for the short term we can bring out the whip and expect a slight jump in productivity, but assuming we want something that lasts longer than a few months and don’t want to experience a McDonalds-esque churn rate (because that would inevitably increase our cost and decrease the quality of our software), let’s throw this option out the window.

Another option would be to hire better people. This has a decent probability of increasing quality over time, but it’s not a solution one can implement overnight. With a team of 20 developers you’re probably looking at nine to twelve months to clean out less-productive developers and fill it with solid talent, assuming you have a few less-productive members on your team. However, if your development team is already a group of “coding machines,” or if your goal is to implement something immediately then another avenue must be explored, even if you decide to pursue this one for the long-term. Training and/or mentoring is a variation of this option with similar advantages, but a similar time-horizon.

Another alternative would be to simply make your people work harder.

Hmmm…this is an interesting one. If you buy what I said at the start of this article, that most developers are already working at or close to their best due to personal or social reasons, then this hypothesis doesn’t quite pan out. How can someone who’s already working at a high level of productivity all of a sudden work harder? Making someone work harder simply by asking them to is…well…hard to understand.
Irrelevant Image: Xela Sky
And that’s why telling someone to build higher quality software in the same amount of time is insulting, because you’re essentially telling them they’re not giving it their best effort. That they’re screwing off.

And that makes people mad.

How do I know this? Because someone said it to me the other day. Not just me, in fact, our entire development team.

Better Software
A non-technical manager told us that we have to build better software in the same amount of time, and even included the phrase “No excuses.”

Needless to say morale has seen a slight decline in the days following as developers express their feelings of defensiveness. People who’ve been giving it their best suddenly feel taken for granted and frustrated, especially the ones who’ve been working extra hours, solving project issues in their spare time, and running performance tests on the weekend. When you’re already working hard it’s difficult to hear someone tell you to work harder.

The talk was prompted by a recent issue where some high-availability systems were down for the better part of a day. These systems were written over the past 4+ years under perilous death-march schedules, with little QA because we were in a hurry to get them out the door. When they went down people panicked, and rightfully so, since many of our customers were foaming at the mouth.

As a result management expressed their concern with the situation, indicating that something had to be done as we move forward. As I was listening I understood “Make better software; reduce risk of failure.” As most developers would agree, this is a great approach, and one that several members of our team have been advocating for for quite some time. I became excited at the thought of ensuring we have ample QA and including more safeguards in our code. But my parade soon ended in a blizzard when I heard “I don’t want to hear excuses about how things are going to take longer. We can get things done fast AND better.” And that’s when I realized I needed to write this article.

Irrelevant Image: Yosemite Rapids

But wait, there’s a little more.

A comparison was made between our software and the software of a large financial organization (think Wells Fargo or Washington Mutual). If you’re thinking “I can’t remember the last time one of those guys was down for an extended period of time,” you’re right; they typically aren’t down, and when they are it’s not for very long. But an interesting thing I’ve learned in the past few years is that the software development cycle for these guys is loooooong, to the tune of 2-3 times what our timelines run.

In other words, they’ve decided to take the “time” side of their pyramid and make it really big in exchange for a really big “quality” side. And good for them, because they’ve obviously made a wise choice, as indicated by their availability.

Now that we’re faced with the same dilemma it’s time to pay the piper and admit we need to lower our risk while at the same time admitting to ourselves the sacrifice that it will ultimately require: time.

The Moral
There are at least two morals to this story

The first is that you will eventually reap what you sow, so don’t compromise your design. Fight tooth and nail and push out timelines if you have to. This is not going to be easy, so good luck. Let me know if you discover any secrets because I would love to hear them.

The other is that reducing risk takes time. At this point I should add that it’s our responsibility as technical folk to educate those who don’t know this. A concept that appears so clear to us may not be apparent to a person outside if the IT department. We’re the only people that truly understand the complexity of the systems we build and the ramifications of spending too little time on design or QA.

Reducing risk is a lot like having insurance – if you elect to have it you have to pay for it.

Send this article to a manager or co-worker who’s tried to convince you otherwise.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Digg this ]

ChitChat.NET Sold!

Thanks to everyone who showed interest in the sale of ChitChat.NET, the ASP.NET discussion forum package I put on the auction block about a month ago.

I recently completed the sale to software entrepreneur and all-around nice guy Mike Taber of Moon River Software. The purchase price will be paid over a few months, but aside from that the deal is complete.

If you’re looking for a low-cost C#/SQL Server discussion forum/bulletin board, ChitChat.NET is your product. You can try an online demo, download an evaluation copy, or purchase it online at www.clickcess.com. And, while you’re at it, take a look at Moon River’s flagship product Milestones, a simple, yet powerful bug tracking and project management tool.

The process of selling was straightforward: I posted it on my blog, sent some emails to people I thought might be interested, and posted to a few software forums. I received a total of six inquiries about the sale, and three offers. I’m happy ChitChat’s going to someone who has time to improve and properly market it.

If you have any questions about the process, post a comment and I’ll answer it in a future post.

New .NET User Group in Los Angeles

Some colleagues and I recently started a .NET User Group in the San Gabriel Valley (Pasadena area). Our first meeting was a rousing success with almost 40 attendees, and we’re looking forward to our second meeting next Wednesday, February 15th from 6-9 pm in Monrovia.

We have a great speaker lined up and I’ll be there MC-ing and giving away crazy stacks of books, t-shirts, and software. The cost is $5 at the door which includes pizza.

Check out www.sgvdotnet.org for full details.

Hope to see you there!

New Eric Sink Article: Yours, Mine and Ours

I’ve been a fan of Eric Sink for a long time, and he’s just published his best article in months. In it, he discusses the difference between MeWare, ThemWare, and UsWare; in other words, software that’s used only by the developer, only by other people, or by the developer and other people. A very interesting read with “the best dogfooding story ever” mixed in. Here’s a quote:

“No matter how much I believed in my product, I think I would find it incredibly difficult to stick my finger in a spinning table saw blade. Unbelievable!”

You can read the article here.

An Annotated List of Software Startup Resources

Joel on Software
One of the first software blogs, Joel on Software is written by former-Microsoft employee Joel Spolsky, who traded in his keyboard for the chance to start his own shrink-wrapped software company. With almost six years of posts and numerous in-depth essays, JoS is is filled with insight, humor, and excellent writing. Joel covers software project management, starting your own shrink-wrapped software company, the business of software, and software design.

Eric Sink’s Blog
Eric Sink was the Project Lead of the team that built the original version of SpyGlass, which later turned into Internet Explorer. Eric started his own shrink-wrapped software company SourceGear in 1997, and writes about topics such as software marketing, leading software teams, MicroISVs (one person software companies) and hiring developers.

Paul Graham’s Essays
Paul Graham writes essays about the fast-paced world of venture-funded software startups. Paul was one of the founders of ViaWeb, which was purchased by Yahoo for $49.6 million in 1998. Paul is a huge proponent of the “hacker” approach of getting as much code written as quickly as possible for as little money as possible, all without a specification in sight. Paul recently started an incubator called Y Combinator that provides funding for college-age entrepreneurs interested in starting technology companies.

microISV is a community for independent software developers, and covers a wide range of topics relevant to one-person software startups, including: development languages and tools, entrepreneurship, software marketing, and microISV-related news.

Signal vs. Noise
Like ’em or not, 37signals is doing something right. Creators of Ruby on Rails and offering web-based project management and information management tools, 37signals has achieved great success with their sleek design and “simplicity rules” design ethos.

The grand-daddy of technology news websites, Slashdot was founded in 1997 by 21-year old Rob “CmdrTaco” Malda. Slashdot welcomes stories from anyone, but publishes around 15 editorially-chosen posts to the main page each day.

“With Digg, users submit stories for review, but rather than allow an editor to decide which stories go on the homepage, the users do.” Just over a year old, Digg is rapidly gaining popularity as a source for technology news. Keep abreast of tech news with one of Digg’s many RSS feeds.

“killer resources for entrepreneurs,” WorkHappy provides reviews and links to websites and services of interest to entrepreneurs.

TechCrunch provides daily reviews of the newest Web 2.0 companies. If you’re interested in this space, or just want to keep abreast of the happenings on the web, take a look at TechCrunch.

Bug Bash
A weekly dose of software development humor in comic form.

The Daily WTF
Whenever I feel depressed about code I’m maintaining, I read a recent post from the Daily WTF.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Digg this ]

Starting a Technology Company: What We Can Learn from Google

With Google’s stock down around 30 points yesterday (almost 10%) after announcing quarterly earnings, this seems like an appropriate time to discuss what we can learn from Google about starting a technology company.

After listening to The Google Story on audiobook last week (which I highly recommend) I was struck by three core principles that had a significant impact on Google’s success and their ability to call the shots when dealing with venture capitalists, investment bankers, and other business-people who have a reputation for taking advantage of small tech companies. These principles apply the most in the early phase of a startup when you’re dealing with angels and venture capitalists and working 14+ hour days out of a garage.

They are:

  1. Have a Partner. Time and time again the two founders, Larry Page and Sergey Brin, were able to confide in one another, argue with one another, and back the other up when making tough decisions. The duo, like Hewlett & Packard, Jobs & Wozniak, Gates and Balmer, left the comfort of their university lifestyle for a chance to change the world with their technology. Along the way they snubbed venture capitalists who weren’t willing to work within Google’s terms, and defied investment bankers with their Dutch auction IPO. Each of these decisions was that much easier because they had the other to rely on.
  2. Have a Vision. From the earliest days of Google, as they worked in a Stanford computer science lab, they had a vision. Their primary focus was not to build a search engine, but to organize the mountains of data generated by the internet; it just so happened that the easiest way to do that was with a search engine. And, for the most part, they’ve strictly adhered to their vision of organizing the world’s information. From their search engine to Google News to Google Library to Gmail, their services are aimed at taking mountains of data and making them usable for everyone. This vision has kept them focused on providing real services that people need, even when it didn’t make them a cent.
  3. Have a Unique Technology. This is easier said than done, but it’s the most important of the three. Their unique search technology was the defining attribute of Google, and it’s what set them apart from other startups of the day such as Pets.com and Kozmo. They consistently used their search technology as a bargaining chip with investors, venture capitalist, and other business-types who almost always have the upper hand when dealing with needy companies. As with companies like Netscape, who also called their shots with venture capitalists, having a difficult-to-copy, proprietary technology puts you in the driver’s seat.

If you’re interested in Google I encourage you to check out The Google Story.