Technorati Profile

Saturday, August 14, 2004

The 5 Laws of Choosing a Software Developer

So you have a software project in mind, and you are trying to choose the right developer to take on your project and bring it to life. But how can you avoid hiring a rank amateur who merely talks a good game, or a pure programmer who understands how to write code, but doesn’t understand your business? After all, it’s easy to claim to be a software developer – no licensing is required, and there are no public records of who has done good work or bad work for you to look up. All one needs is a computer and some books, and a "programmer" is born. This low barrier to entry makes life difficult for both the clients and the competent developers. Luckily, you can save yourself a lot of trouble by demanding these 5 items of any software developer you hire.

1) Demand Experience. Unlike the stock market, past performance is a great indicator of future results when it comes to evaluating a developer. Certifications and degrees are good, but they only tell part of the story – it's better to look for your prospective software developer to have at least 5 years of experience in positions of ever-increasing responsibility. For most small business projects, you need someone who has done more than just write code; the ideal candidate will have experience successfully leading entire projects from start to finish. A person who has worked as a programmer can write code, but an actual developer is a notch above that – someone who can analyze your business needs, design the project, write the code, implement the project and provide support afterward.

2) Demand References. Ask your developer candidate for a list of references, and be sure to contact them. In addition to asking about technical competency, ask questions about the developer’s approach to customer service – is the developer available by phone or eMail a reasonable amount of the time? What kind of a response does the developer give when asked for emergency or non-emergency help? Along with the references, you should ask to see samples of work the developer has produced that is similar to your project. If the developer asks you to sign a non-disclosure agreement before showing you these samples, that is reasonable.

3) Demand Value. You should never select the least expensive developer you can find; that virtually guarantees that you are hiring an amateur, and will get your project in trouble. Instead, look for the best value – the place where price and results meet. An exceptional developer might outperform a mediocre one by 10 to 1 in some cases, but cost only 1.5 or 2 times more; that means your total project cost could potentially be much lower than if you hire a less-skilled developer who lets your project get out of control. Some developers will request that you pay a deposit at the outset of the project - this is reasonable, and is a common business practice.

4) Demand Communication Skills. If you show me a person of average intellect with exceptional communication skills, I will show you a person who can be trained to be a better software developer than most of the introverted geniuses you hear about in this industry. The best developers out there have taken the time to learn how to speak your language – the language of business – and will happily listen to your comments, opinions and concerns, then explain to you in plain English how their proposed solution is going to work, and how it is going to help you. If you find you are unable to communicate effectively with each other, it’s best to move on to the next candidate.

5) Demand Availability. Nobody expects a software developer to have only one client or project at a time; it’s just not realistic. At the same time, you need to avoid hiring a candidate who is hopelessly over-committed. The first thing to consider – when can the developer schedule your project to begin and end? What is the developer’s current workload? What kind of a schedule can you expect your project to progress on? How often can you expect milestones to be completed? If you have a hard deadline, discuss it with your candidate; make sure the developer can commit to meeting it.

Wednesday, August 11, 2004

Repeat After Me: I Am Not In The Software Business.

As I work in this industry on a daily basis, I come into contact with more and more people who write software in one fashion or another. Some are hobbyists, some are small business owners trying to be more productive, and some are professionals who get paid to write code and develop software. I am always surprised at the number of professionals who, by word or deed, express that they are not concerned with business problems, only with technology problems. I've worked with people who will gladly stay up all night long trying to figure out why IIS isn't delegating security credentials from one machine to another, but are absolutely uninterested in figuring out whether or why the business needs a web application in the first place. I am an artiste, this particular subset of software professionals seems to say.

If you've ever encountered one of these types, you know it. And although these folks are in the minority within our industry, they are visible enough to give us all a bad rap - one bad apple and all that. So for the benefit of everyone who creates software in one way or another, let me say this:

You are not an artiste.
You are not even in the software business.
You are in the problem-solving business.
More to the point, you are in the business-problem-solving business.
The technology problems you solve should always be in the context of solving a business problem.
If the solution to a particular business problem offers less benefit than the effort required to solve it, you should be working to solve a different problem.

There, I said it. A lot of people will not like hearing this. Some will disagree vehemently. And that is OK. But the truth remains - it is the job of the software developer to solve problems. Technology does not exist in a vacuum. A well-written, elegant, extensible, scalable, n-tier application has no intrinsic value. It is only when such an application solves a business problem that it creates value. That's why we call them applications - unless the software is doing something, it's just bits and bytes on a disk someplace. As a profession, we need to get hip to being able to recognize and understand business problems.

In fact, sometimes technology is not the solution to a given problem at all. Just the other day a client asked me to re-write a portion of the home-grown application he uses to run his business. I declined, pointing out that a simple change in process in his back office would solve the problem they were having. A pure technologist would see this as a technology problem, when in fact it was a very simple business problem. Now, I could have re-written that module and made a decent amount of money doing it. And sure, that would have solved his business problem just as well as the process change would have. But there was no need for that particular expenditure of time and money to be made.

It is important to avoid the old "when all you have is a hammer everything looks like a nail" type of thinking. And personally, I think a lot of us need to be reminded of this fact. Admittedly, my point of view is colored by the fact that I didn't study computer science in college - I studied management. But the most successful developers I've met are the ones who, regardless of training, are able to understand that technology supports the business need, not the other way around.

Now, lest anyone think I'm belittling programmers or software developers, I am not - remember, I make my living in this industry, too. I stated earlier that I am talking about a relatively small but visible subset of the profession. As developers and programmers, we possess specialized skills that are frequently vital to the effective operations of businesses big and small, just like the specialized skills possessed by accountants, craftsmen, managers, and salesmen. It is all part of the great mosaic that makes up a business. I believe we matter in the workplace, and we matter a lot - so long as we remember why we matter. We matter because we solve business problems. Those of us who are content to flip bits and bytes with no desire to understand "why" in a business sense, or with no desire to make the bits and bytes line up with business value, are at the very least wasting the valuable material between their ears.

To have a desire to code - and only code - for a living is OK. But to wear blinders while doing said coding for a living is not - that effectively reduces you to the role of an assembly line worker who adds his piece to widget as it rolls by on the conveyor belt, never to see or understand the completed product. And I think that good coders and good developers are much, much more valuable than that and have much, much more to offer.

To those who shy away from business issues, I say: come out of your shell. Nobody is asking you to be a business analyst, but at the very least, always seek out the business context of what you are working on. Always. At the very least, always seek to be better informed and truly understand why you are building what you are building. Always. It is better for your clients. It is better for your career. It is better for the image of the profession. And it is better for the economy at large.

Discuss 'Repeat After Me: I Am Not In The Software Business' here

Wednesday, July 28, 2004

You Can Never Be Too Thin...Or Too Rich?

The war between the thin client and rich client rages on. According to a recent item on CNN, IBM intends to push the thin client to new heights with its Workplace product. We all know the stated advantages of served-based computing and thin clients - ease of deployment, lesser support cost, greater portability, and so on. These are good things to have, certainly. IBM is probably being realistic about this product, realizing that Workplace alone is not going to break the Windows stranglehold on the corporate desktop. Personally, I continue to maintain that the desktop is never going away. After all, power and ownership are still big factors with people when it comes to computing - hard drives and memory are way too cheap to NOT make good use of. A terminal hooked up to a server is only going to be able to do so much.

That said, I welcome the new old thing. I'm sure that the swinging pendulum will continue to move toward terminals for a few years, then desktops for a few, back and forth until someone comes up with a truly new paradigm for computing at work or at home. In the meantime, there's more than enough diversity in the world of computing for both thin and rich clients.

Discuss 'You Can Never Be Too Thin...Or Too Rich?' here

Thursday, July 15, 2004

Necessary Rudeness and the Effective Use of Your Time

Pop quiz, hotshot - you have a task of known importance in hand. You have an interruption (phone call, eMail, fax, someone hovering in your doorway) of unknown importance coming in. What do you do? If you're truly interested in being effective, you turn off your ringer, close your office door, and shut down your eMail client until you're done with your task.

Here's a scenario - tell me if it sounds familiar. You're diligently trying to maintain your focus on a critical task, only to hear your phone ring. You answer the phone, provide the answer to a co-worker's question (a questions could have been answered by Googling), then return to your task. Blinking your eyes twice, you get yourself back in the groove and continue. A few minutes later, another phone call with another question pertaining to an issue of low urgency. Again, you breathe deeply and slog onward with your task...until another phone call comes in. And an email with the little red flag indicating that the message is "urgent" pops up in your Inbox, so you start reading it while you're on the phone. Then you notice Bob from Accounting hovering in your doorway, asking if you "have a minute" as you try to type an eMail reply while finishing up your phone call. Then a phone call comes in on your other line before you are done with the call you're on. Wait, what was I trying to do again?

Let's look at the culprits here:

1. The Phone. The telephone is, without a doubt, the #1 most ruthless time-waster in business life today. And not only do we have them on our desks, we strap phones to our belts and carry them with us all day! The specific problem with the phone is that while you know exactly how important your current task is, you have no idea if the next phone call you take will be a trivial question or a bona-fide emergency. Here's a hint: true emergencies are few and far between. To paraphrase Dan Kennedy, never interrupt a task of known importance for a potential task of unknown importance.

2. eMail. Ah, eMail. I love eMail. But even eMail has a dark side - when someone sends you an eMail in an office environment, they know that you receive it more or less instantly. This often leads people to expect a response more or less instantly. Every office has at least one person who follows up every eMail with a phone call "just to make sure you got my eMail". If you are going to make effective use of your time during important tasks, you must not allow anyone to pressure you into providing a reply according to any timeline other than your own. Shut down your eMail client when you're working on important tasks. Fire it up when you're not. It's simple, but so few people do it.

3. The Person Hovering in Your Doorway. If you are in the midst of working on a truly important task, your office door should be closed. If you do not have an office with a door that closes, it is acceptable to simply not acknowledge a person who hovers in your doorway. Let the person announce himself or herself. Then you have a few options. I used to offer "5 minutes now or 30 minutes by appointment later". I found that almost everyone prefers to take the second option, which is good. It allows you to continue your task, and it gives the other person a chance to gather some info and bring you a well thought-out issue to discuss, rather than some extemporaneous doorway rambling. It also sends a message to other would-be time-wasters that they need to have their game in order before approaching you when you're in the middle of an important task.

I will go so far as to say that if you are not 100% unavailable for at least 2 hours a day, you probably aren't getting much done that's of any importance.

Now, despite the title of this post, I do not advocate being rude to people; quite the opposite. The term "necessary rudeness" is meant to acknowledge the fact that if you make yourself unavailable while working on critical items, some people will perceive you as rude, and this is OK. Most people - the ones who are themselves effective - will understand. Those that do not understand are likely to be the same people who don't accomplish much. Open-door policies and their ilk sound fantastic in corporate seminars and on the dust jackets of business books written by guys who've never really run businesses, but in the real world being too available rarely does anything but allow people to take advantage of you. Ours is such a culture of accommodation that we often forget that getting things done is what keeps us prosperous. During times of critical work, it is acceptable to demand that people respect your time. During times of critical work, it is acceptable to demand that people call ahead rather than hovering in your doorway, trying to interrupt your task. During times of critical work, it is acceptable to refrain from answering faxes and eMails immediately - that the message is delivered instantly does not entitle the sender to an instant response.

I can almost hear all of you lone-wolf, "slide pizza under the door until I tell you I'm done coding" types rejoicing as you read this, ready to print copies out and tack them up in your cubicle in an attempt to justify your teamwork-avoidant behaviors at work. Don't worry, I'm about to burst your bubble. :P

The flip side of all this is that you must be able to determine which tasks can afford no interruptions, and which ones can. If you are unable to make this determination you will either fail to get the truly important tasks done, or you will fail to provide sufficient value to your colleagues and customers to keep yourself employed for very long. Nobody works in a vacuum, and it is critical to strike the right balance between single-minded focus on critical tasks vs. availability to support your team and customers. When you know that your task is of the highest importance, by all means turn off your ringer, shut down your eMail client and close your office door until you are done. But be surgical about it - when you switch to working on relatively routine tasks, make yourself available. And remember to extend as much respect for the time of your colleagues and customers as you demand they show for yours.

It is a difficult balance to find, and being able to find it is one of the marks of a true professional. Finding this balance it will make you more productive and much less frustrated.

Discuss 'Necessary Rudeness and the Effective Use of Your Time' here

Sunday, July 04, 2004

Celebrating Independence Day

Happy Birthday, America!

To live in America is to enjoy some very unique blessings in terms of standard of living and opportunity. Sure, many people who read that statement will immediately point out America's flaws, reminding us that things aren't perfect here - but they're not perfect anywhere else either. It is as important to recognize and appreciate our positives as it is to recognize and strive to remedy our negatives, is it not?

In no other place and at no other time in human history have so many lived so well and had access to so much. I believe we sometimes allow ourselves to forget our good fortune far too easily, which is something that we must be ever-vigilant against.

You and I are fortunate enough to live in a place that offers tremendous potential to anyone willing to exhibit some hustle and intelligence. Let's all promise each other not to ever take that for granted.

Saturday, July 03, 2004

Discussion Forums Now Open

My discussion forum is now officially open, as evidenced by the new 'Discussion' link in the navigation bar. I put the forum page in place a number of weeks ago, but only recently tweaked it to behave to my satisfaction.

Get in there and start a discussion! Or just take a few minutes to tell me why I am wrong, wrong, wrong on any topic I've produced an article about.

Wednesday, June 30, 2004

RSS Feed now available

For those of you who've been badgering me about adding a feed to my site, here it is.

Tuesday, June 29, 2004

"To Have More, Become More"

Jim Rohn, quoted from this week's Gitomer newsletter:

When asked, "How do you develop an above average income..." a friend of mine has always answered, "Simple. Become an above average person. Work on you." My friend says, "Develop an above average handshake." He says, "A lot of people want to be successful, and they don't even work on their handshake. As easy as that would be to start, they let it slide. They don't understand." My friend says, "Develop an above average smile. Develop an above average excitement. Develop an above average dedication. Develop an above average interest in other people." He says, "To have more, become more."

Simple, undeniably true, and yet so easy to forget.

Friday, June 25, 2004

21 Rules of Thumb - How Microsoft Develops its Software

Best blog entry ever? It is possible.

This morning's edition of David Gristwood's blog boasts an absolute gem entitled 21 Rules of Thumb - How Microsoft Develops its Software. The item, originally written by Jim McCarthy, deals with how to get a team to gel, be productive, and produce great software. To be perfectly frank, I feel extremely validated reading it. Most of the things on his list are things that I have pushed for at development jobs over the years, but have rarely gotten through official channels (although I usually implemented similar practices on whatever team I happened to lead anyway). Now that I run my own company, however, I can implement any development guidelines I like. Let's look at the top 3 items from Microsoft's playbook:

1.Don't know what you don't know.

It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn't early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you.

2. Get to a known state and stay there.

The function of QA is to know (and articulate) the quality of the product at all times in the development cycle. This should be achieved by abbreviated, repeatable tests conducted daily, and full product sweeps conducted weekly or biweekly.

It is not properly the job of QA to determine when a product is ready to ship; rather, the moment of shipworthiness in a product development cycle is evident to everyone involved, and is non controversial. This is because shipping has been the goal of the entire effort. Crossing the finish line, while it has intangible emotional and definite financial rewards, is no surprise when you've observed every single painful step toward it.

The only reason you've been able to make these micro-observations is because you got to a known state and stayed there, and your QA is how you did it.

3. Remember the triangle.

There are only three things that you are working with as a development manager: resources (people and money), features and the schedule. Changing one has an impact on at least one other axis, usually two. It is a simple enough matter to mentally run through the sides of the triangle, or force others to do so, when discussing any part of it. Since the people, the product or the schedule is almost always what you're discussing, this means that you must constantly envision the triangle. This leads to the most fruitful line of thought.

Those are just the top 3 items from the list; take a look at the remaining items. You'll find things like "Low tech is good", "Beware of a guy in a room" and my personal favorite - "Never trade a bad date for an equally bad date".

Now if only I could answer the question of why so many organizations fight these type of best practices tooth and nail...

Wednesday, June 16, 2004

Excellent Interview with Scott Collins of Mozilla

ArsTechnica has posted an excellent interview with Scott Collins from Mozilla.org. He covers open source, Mozilla mistakes, and competing with Internet Explorer.

Tuesday, June 15, 2004

More Feedback on The 5 Pitfalls

Regarding The 5 Pitfalls of Estimating a Software Project, Jonathan writes in about an estimate his manager asked him for:

"His first comment was that he had never seen an estimate given in hours. I explained to him that I didn't like to give dates because of unexpected company meetings, sickness, etc. I don't think this ever occurred to him. His second comment was that my estimate was too large and that he would have to "massage the numbers" so that the executives wouldn't be upset. I was absolutely furious. What's the point of even asking me if you're not going to listen to my answer?"

I'm getting a lot of great eMail feedback on the 5 Pitfalls, but not much in the discussion forum. Everyone feel free to drop a comment in there about any item in this blog - for that matter, feel free to start new topics to discuss.

Discuss 'The 5 Pitfalls of Estimating a Software Project' here

Monday, June 14, 2004

Feedback on the 5 Pitfalls

Richard Caetano over at Strongly Typed made a great comment related to my 5 Pitfalls of Estimating a Software Project item:

"An off-the-wall thought: When I'm able to pull if off I do a project/time estimate as the inverse. I ask the customer how much time I have...then figure out what I can do in that amount of time. In a way a time estimate is a requirement. What good is a product if it can be delivered on time (which may be at arbitrary length) but not at an *applicable* time."

Richard brings up an interesting point - sometimes you get a project that is only useful to the client if it can be implemented by a certain date. I often had to do the kind of inverse estimating that Richard refers to when I was building variable compensation systems; those Fortune 500 companies do their compensation processing on a certain schedule, and if I couldn't deliver certain features by certain dates, the value of those features dropped to 0 until the following year! These days, most of my consulting work falls into the category of "things the client wants to do as soon as I can build a tool to do it with", but that is not going to be the case with everyone and it is good to bear in mind that sometimes you have to back in to your estimates.

Now that I'm thinking about it, backing into an estimate is also a great help in managing expectations. Once you present an estimate containing x number of features, if the client later has to change the due date for some reason, they won't always understand when you come back and tell them that given the new date you can only deliver x - y features. They won't always understand why you can't just "work faster" and deliver the original feature set - they're experts in their own businesses, not in the very unique (and sometimes strange) rules governing software development. Some might even be taken aback and think you are punishing them for giving you less time to do the project. It sounds outrageous, but it does happen.

Better to present an estimate with fewer features that you KNOW you can implement in the time allotted, if date constraints exist prior to your taking on the project.

Discuss the '5 Pitfalls' here

Saturday, June 05, 2004

Site Changes here at ChristopherHawkins.com

As everyone who visits my site - yes, I mean both of you - can tell, I've been doing some cleaning up. I'm hoping the revamped is cleaner, more readable, and more interesting than the previous incarnation. The big changes are :

• Condensing the site from about 20 pages to 5 more focused pages
• Changing the overall look
• Adding a weblog
• Adding a discussion forum

Thursday, June 03, 2004

How Wrong Can One Guy Be?

I just caught this article in the Seattle Weekly. The author is a former Microsoft employee who now embraces the Mac platform and now has predictions of doom and failure for his former employer.

So how can the supposed failures of Microsoft be sensationalized? Let me count the ways:

Why are Microsoft products so endlessly frustrating to use? Even techno-geeks like me get annoyed by Windows. I'm tired of spending the first 10 minutes of my day rebooting just so I can get to work. Microsoft Outlook 2003, the latest version of the company's e-mail and calendar software, hangs for me about once a day, requiring me to restart my PC. I also have a problem with Word 2003: Whenever I bullet a line of text, every line in the document gets a bullet. Asking Windows to shut down is more of a request than a command-it might, it might not. And recently, Internet Explorer stopped opening for me.

But in the first five minutes on my new Mac, I was surfing the Internet, sending e-mail, and ripping a CD. OS X has been a breath of badly needed fresh air after Windows.

This made me wonder about Microsoft's willingness to innovate and compete. Why are Microsoft products still so difficult to use and so unreliable? Why is the company improving them so slowly? Is Microsoft losing its competitive edge? Has the company seen its best days?

Jeff, here's some news for you: it is OK to decide that you prefer the Mac platform to the Wintel platform. No, really - it's OK. This is a free country and if you love your G5, more power to you. But what is NOT OK is writing up hyperbole and inaccuracies in order to justify the change.

Discuss 'How Wrong Can One Guy be?' here

Tuesday, June 01, 2004

The 5 Pitfalls of Estimating a Software Project

I am frequently asked why software projects are chronically late and/or over budget. Naturally, I always take that question as an opportunity to brag about not having gone more than 10% over any estimate since 1999. ;)

It took me 6 years to learn how to produce an estimate that accurate, however, and along the way I've noticed a set of behaviors that always lead to blown estimates and broken budgets. Avoiding these pitfalls will put any organization on the road to more accurate estimating, happier clients, and profitable projects.

1) Allowing non-technical staffers to give estimates. I know, I know, you think I'm about to launch into a typical software developer's tirade about how talentless the people on the "business side" of the house are - but I'm not a typical software developer. I will say, however, that allowing a non-technical employee to provide an estimate for completing technical tasks makes about as much sense as allowing a hardcore C++ programmer to commit the company to a marketing plan of his own design. I'll even go so far as to say that NOBODY should be allowed to give an estimate for a piece of work except for the person who is actually going to perform the work.

Remember Adam Smith? He wrote an obscure little book entitled The Wealth of Nations, maybe you've heard of it. In it he argued for the specialization of labor, using a pin factory of the day as an example:

"...where each of a dozen workers engaged in only one part of the process of manufacture, so that together they produced far more pins than if each worker produced whole pins; the price of pins then fell, and more pins could be used by more people."

When businesses violate the principle of specialization of labor with regard to creating their product, trouble is soon to follow. It is far better to allow the specialists to do work that falls within their specialty than it is to placate a client by giving a totally fictional estimate.

Because of the Iceberg Effect, a salesman out in the field is likely to think to himself, "Well, that's just a couple of screens and buttons, it shouldn't take very long". So he gives the client a number, and the number may as well be 1 hour or 1 million hours, because it cannot possibly have any connection to reality unless it comes from the person who has to build the item being estimated.

Let your salesmen sell, your marketers market, your executives execute, and your developers develop...estimates, that is.

2) Being afraid to look in the mirror. Most development shops I've interacted with do not do any "post-mortem" reviews at the end of an over-budget, past-due project (or even a successful project, for that matter). Therefore, they never learn what went wrong, never disseminate information that can help other teams to avoid what happened, and then promptly repeat the exact same mistakes. This causes the next project to be over-budget and past-due, and that project doesn't get reviewed either, so the same mistakes are made on the project after that, and so on. Even seasoned developers of whom you would expect sufficient experience to avoid common pitfalls fall into this trap.

Don't be afraid to take a look in the mirror and ask "what did I do wrong?" - this applies to everyday life as much as it does to software development. Always analyze your projects for both mistakes and best practices. Failure to do so is the equivalent of flying a 747 without visibility or instrumentation through the Himalayas; way too much risk for most client's tastes (and checkbook).

3) Underestimating design time and debugging time. Most software developers are not in tune with The Business, they are in tune with The Thing - that is, they focus tightly on the act of construction and sometimes miss the other, equally vital, things that go into a successful project. Design is one of the most commonly underestimated things, I think.

Figuring out how to build something takes time - sometimes more than it took to figure out what to build. On the other end of things, debugging and refining and polishing up the code takes more time than anyone ever anticipates - in fact, in my 11 years in this business, I have never seen an accurate debugging estimate. Never. Not once - except for my own, of course. ;)

Budgeting 50% of total development time for debugging is absolutely reasonable, if not necessary. Any developer who fails to accept this is still in the Age of Unlimited Wisdom (more on that later).

4) Inadequate/unclear requirements. Gathering requirements is difficult, gathering requirements well is rare, and gathering requirements correctly before asking a developer to start designing is just this side of miraculous. I would estimate that 90% of my pre-consultancy projects suffered from inadequate requirements. Ask any developer - they all have war stories about the unbelievably poorly-written spec that had more holes in it than Swiss Cheese when they got from the Business Analyst (to be fair, Business Analysts have war stories about OCD-affected developers who suffer from "analysis paralysis" and cannot do anything without every fact under the sun available to them first, but I digress), and most of those stories are true.

It is tempting to rush the requirements gathering process. It is tempting to just assume the answer to questions that are not addressed in the requirements. Mapping a client's business process is hard, and very few people want to do it - those that actually relish the task are of a rare and strange breed. Uncovering and documenting every seemingly hidden nuance of how a company does business is hard. Going back and forth until everyone agrees that what is detailed in the requirements is an accurate representation of needs to be built is hard. There is a tremendous amount of room for inaccuracies to creep in, especially if you are in a rush.

By slowing down just a little bit - and by little I'm talking 10% - and making sure that the requirements gathering is done right before construction begins, everyone will end up happier and the project is infinitely more likely to be a success.

5) Taking too large a bite from the apple. I cannot count the number of times I watched in horror as a project manager approached a junior programmer, asking "How long will it take to do X?", only to hear "Not very long - maybe Y hours" in response from the snot-nosed young know-nothing. Now, whether X was "re-write Microsoft Office from scratch in Assembler" or "change the color of this font on the home page", the only correct answer to that question is "Let me see the requirements". And if you don't have requirements, you need to get some, even preliminary ones. Even then you cannot commit to anything better than a "plus or minus 50%" estimate until everyone has agreed that the requirements are complete. Even then you cannot give a good estimate until you break down the requirements into bite-sized chunks.

That is the secret weapon of estimating - the more small chunks you can reduce the requirements to, the more accurate your resulting estimate will be. But most people are lazy. Analyzing requirements is almost as difficult as gathering them, and again - very few people want to do it. Those that do will consistently deliver more successful projects than those who do not.

I'm not saying anything here that people in the industry don't know. But I am saying a lot of things that people in the industry don't do. I wish that were not the case, but I can only control my own projects.

Discuss the 5 Pitfalls here

Sunday, May 30, 2004

Yes, RSS Is On The Way...

...although I can't imagine why anybody would want an RSS feed to this poor, neglected blog of mine. Still, to the few of you who have eMailed me asking if I'm going to set up a feed, the answer is "yes, as soon as I have a spare evening".

I am also going to implement a simple discussion board when I get a chance.

Wednesday, May 05, 2004

Beaten To The Punch...Again!

I remember waaay back in 1996 when I thought to myself "Self, it sure would be cool if somebody would market computers with brightly-colored cases. Gee, maybe I'll do it!" I never took action. Two years later the iMac was born.

Then there was the time when I thought to myself "Self, wouldn't it be spiffy if these was a way to seamlessly swap files with anyone over the internet without having to use eMail?" Yeah, the idea was so spiffy that Napster did it just a few years later.

Well, it's happened again. Just a handful of months ago, I thought to myself "Self, why are there so many people who know how to write code, but completely fall down on every other aspect of developing software? Maybe I should write a book about that!" And lo and behold, Mike Gunderloy beats me to the punch with Coder to Developer: Tools and Strategies for Delivering Your Software.

Of course, Mike being a legend in the industry and me being - well, nobody in the industry, odds are that no one would have ever read such a book if I had written it, whereas everyone in the industry is likely to at least skim a book with Mike's name on it. So that is a good thing - I'm sure tons of coders are going to read this and learn something useful. Heck, I'm going to read it and will probably find it useful!

Now, wouldn't it be cool if someone could invent a way for everyone to communicate via their computer? You know, we could have these things called "pages" that everyone could read, using a program called a "browser"...

Discuss 'Beaten to the Punch' here

Saturday, May 01, 2004

Gmail Mania Grips the Masses

It's official...Gmail invites are the hottest thing since Willy Wonka's golden tickets. You show me any message board on the internet and I will show you at least one "Beg for a GMail Invite" thread. Things get even deeper if you hit the blog of any Google employee. I am ashamed to admit that I actually contributed to one of these "me too" threads. What a chump.

Why is this so hot? After all, it's only free eMail, and we've all got free eMail already.

I'll tell you why it is so hot: Google has street cred unlike any other company out there right now. Their technology is proven and their corporate mantra resonates with the geek demographic. In short, we implicitly trust Google to deliver the goods. I challenge anyone to name something Google has offered that sucks.

Nobody knows when GMail will be officially launched, but until that golden event takes place you can bet there will be people continuing to scour the internet in search of extra invitations.

And all I have to say about that is...invite, please? ;)

Tuesday, March 30, 2004

My First Published Article

I'm very excited to say that I have been published (in print) for the first time. I wrote an (admittedly cheesy) article for the Visalia Chamber of Commerce monthly publication.

Sure, it's not Visual Studio Magazine but it is a start.

Edit: looks like the Chamber wipes out all the previous month's content when they post the next month's newsletter on the site. The link I previously had is now dead. Maybe I'll post the article here when I am no longer ashamed of the unabashed marketing angle of the piece. ;)

Thursday, January 01, 2004

Happy New Year!

As much as I hate to do it, I'm going to commit (publicly, no less!) to some resolutions.

• Double my consulting income over last year. Ordinarily I do not like money-based resolutions, but as a self-employed fellow, I have to have SOME metric by which to measure my progress.

• Earn an MCSD certification by year's end. I have been fighting this since 1997. I believed - and continue to believe - that certification is a slippery slope that leads ultimately to an artificial limitation on billing rates for both the certified and un-certified (more on that another time). However, I cannot argue that the market has embraced certification to a significant enough degree that I cannot ignore the marketing value of the cert. Like it or not, a certification - like a degree - is seen as a proxy for knowledge and/or capabilities. Sure, I could learn all the same material and not get certified, but if I'm going to end up learning it anyway I may as well have a marketing tool to show for it, no?

• Spend an extra hour each day playing with my son. We play a lot. And when we play, we play goofy. It is a lot of fun. And I intend to serve up a double-helping of playtime this year. Being a father is the single greatest role I have ever played - programmer, husband, boxer, provider, employer, employee - everything else pales in comparison to the quiet sense of satisfaction I get from my son. I intend to make the most of being a father.

• Compete in one amateur boxing match by year's end. "Boxing!?!" you say. "But Christopher...you're a geek. People are supposed to beat you up, not the other way around!" Well, it's been a long time since I was that skinny kid getting picked last for kickball during P.E. class. I boxed a bit in high school, dropped it, then picked it up again about 2 years ago to get in shape. I still have the competitive bug, and at age 31, if I don't satisfy it soon while I still have decent skills and a reasonable ability to heal, I likely never will. Some people kick a ball for fun, I get hit in the head for fun. That probably explains a lot of my code.

Monday, December 01, 2003

Guess Who's Coming to Blog?

This re-launched ChistopherHawkins.com marks my entry into the blogosphere. I intend to avoid authoring a "today I ate lentil soup for lunch" blog and more of a "today I learned something cool about technology or business" blog. We'll see if I manage to live up to that lofty aspiration.