Bob on Development

February 23, 2007

More on “Cheap” Software

Filed under: Managment,Projects — Bob Grommes @ 2:53 pm

Last month’s post on this topic has proven very popular.

Recently, Web Worker Daily posted about ways to make money online, and one of the ways listed was to troll the freelance programming marketplaces.

Naturally I couldn’t resist commenting that I could not figure out how anyone can make honest money from those sites!

Warren Seen of Tasmania, Australia mentioned his excellent freelance programmer’s manifesto that I highly recommend you take a look at. I only wish he had called it the freelance software developer’s manifesto. It’s a positioning thing; “programmer” evokes the image of some kind of rote technician or assembly line worker; “software developer” is in my view a much more accurate way to describe what we do. We do not snap together things so much as organically evolve them.

In response to someone’s remark that “people with an eye for quality will always pay a premium for the right kind of service”, Warren also makes the point that “quality as a unique selling point is difficult in software”. How right he is. In a way, your clients have nothing but your word that your $90 an hour efforts have any more value than someone else’s $7 an hour efforts. If this perception were not tripping clients up, there would be no offshore labor market to contend with.

That is why developers must realize they are in a marketing game as much as a technical game. That is one reason I avoid using the term “programmer”. There are clients with “an eye for quality” and you want to attract those kinds of clients. As you get acquainted with the right kind of clients you learn what they like to see. Confidence, honesty and excellent communication skills (both orally and in writing) are important.

Another thing I’ve found invaluable is making clients feel in control by educating them in layman’s terms about what I’m doing and why, and what to expect next. This really differentiates you from someone who says “Sure, I can do that, it’s very simple and inexpensive” and then disappears, only to return (usually late) with something that’s not what the client actually wanted, is full of bugs, or turns out to be impossible to maintain.

All of these practices, coupled with best practices, lead to the truly “affordable” software … the stuff that’s on time, works right, is stable and flexible, and delights the customer. There are no shortcuts.

Lastly, to turn this discussion around, let’s look at the wrong kinds of clients and the whole issue of when to say “no” to a project. You can’t afford to waste your time on abusive clients with unrealistic expectations.

Some clients are dead giveaways — like the fellow who wanted to hire me to clone the Google search engine in six months, and then when speaking of compensation asked me “how much lunch money to do you need?”

Others are more subtle. Constant pressure to do things before they’re done is a major clue, though. In his excellent post, “Programmers are Brain Surgeons”, Sau Sheong Chang asks the rhetorical question, “if your brain surgeon said some procedure would take five hours, would you pressure him to do it in three?” (He gives credit for this quote to Scott Berkun in The Art of Project Management).

Now I grant you I am not as highly educated and trained as a brain surgeon and the software I write seldom influences life-or-death scenarios. But the point here is not that I’m trying to suggest what we do is as awesome as brain surgery; I’m suggesting that the results of rushed software development and rushed brain surgery will be equally unsatisfactory.

Another similarity between the two professions is that if a brain surgeon encounters unexpected problems he does not stop at five hours and walk away; he spends as much time as necessary to complete the job and overcome any difficulties. Clients who have a cow because you estimated five hours and spent ten on a task, just don’t understand what this game is all about. (Naturally if you always take twice as long as you estimate, you need to quit being so optimistic, but that’s a topic for another day).

Clients who always push you to do things yesterday either don’t trust you and assume you are always highballing your estimates; or, they are trying to take advantage of your desire to please them; or they are just plain clueless and cheap. Either way, they are toxic clients.

“Quality” trumps “cheap” any day … for those clients who can appreciate the difference and those developers who can help them appreciate the difference.

February 9, 2007

What PayPal, eBay and UPS Can Teach Us About How NOT to Treat Online Customers

Filed under: Managment,Products — Bob Grommes @ 4:11 pm

Two starkly contrasting things happened to me today. One of them makes me want to ram my head repeatedly into the wall, and the other one gives me faint but distinct hope that mankind is not about to be drawn into a bottomless suck-hole of mediocrity and indifference. In these experiences are some lessons for software developers designing customer-facing web sites, as well as some insight into how the devil such abominations can possibly be so common.

First, the head-ramming experience.

It started out simply enough. I had an LCD monitor to sell. I will spare you the details, but with my wife’s help (she’s been through all this before) we got the listing up on eBay and after a mysterious delay of a few hours, it actually showed up in eBay’s search engine, and was purchased by someone using “Buy It Now”.

So … item sold, the money is in our account, the item is packaged … story over, right? Ah, it was just beginning.

First, there is a feature integrated into PayPal where you can buy a UPS shipping label for this item. Great. So you enter the weight, the dimensions, and the value. The value I entered was $1650. The resulting error message: “The insurance valuation you’ve entered exceeds the maximum allowed.” No indication what the maximum would be, or how this could possibly be a problem since UPS will let you buy up to $50K of insurance if you’re so inclined.

I played around with different values (with and without the cents places) and figured out that anything over $1000 is apparently too much, but $1000 or less results in the message that “You have entered an invalid value”. Then it all came back to me that I’d sold something on eBay maybe 8 or 10 months ago and ran into this VERY SAME BUG which, incredibly, is STILL not fixed. Even though my customer had paid for insurance, I couldn’t actually insure the package.

So I did now what I did back then … said the heck with it, and went directly to ups.com. There, I was presented with a verbose JavaScript alert() (the kind that most end users just cancel and don’t even read) that said words to the effect that because I had such a high valuation on the shipment it had to be handed personally to a UPS employee and signed for, which gives me a choice between a 15 mile trip to the nearest UPS store or requesting a pickup. No problem … I’ll request a pickup. Sorry, no same-day service — they can’t pick up until Monday. And now I can’t back out to un-request the pick up.

In the end I voided the shipment and started all over, but now even though one of my two attempts shows in my shipment history as voided, they’ve still charged my credit card twice. Ah, I remember this happening before, too … it will get credited, eventually, in a couple of weeks. Still, it’s on my calendar to check up on this in awhile.

As a humorous coda to this whole thing, I phoned UPS to ask a human being whether I could get same day pick up, as I’m sure I’ve done in the past. The voice mail system took my name, address and tracking number, which of course, the human had to ask me for anyway (why do 95% of voice mail systems ask you for information they don’t give to the person you end up talking to anyway??!?!). But the recording did say I could pay extra for same day pickup. Then the human told me, no, the earliest they could come was Monday, and would that be okay? I asked if there wasn’t a fee I could pay for same day pickup. “Oh,” she said — “if you want same day pick up, you have to call the day before!”

At this priceless line I dissolved into manic laughter. I doubt the operator knew what I was laughing about. She seemed peeved. But I felt better, in a perverse sort of way.

So here we have three soulless corporations — er, multinational enterprises — all of which are doing their part to make what should be the simplest part of my whole customer experience a major pain in the touche. How can this possibly happen?

Let’s take the three-paragraph JavaScript alert() about the need for a UPS employee signature. Now … I’ve paid for insurance … what they are telling me is that insurance is worthless if I don’t personally hand the shipment to one of their employees. Although I suspect they’d be glad to charge me anyway. Somehow I suspect there isn’t a business rule that says to refund the insurance fee to me if it’s over X$ and they didn’t get a proper acceptance signature.

Is this corporate malfeasance, or just something that was bolted onto their web app in a rush one day and no one ever got around to fixing it? You be the judge. I suspect it’s somewhere in between: there is no financial motivation to do a better job, and some motivation to leave it the way it is, whether or not it was initially intended to increase net insurance revenue.

Okay … I promised you a contrast to this depressing incompetence.

I do some work for a business-to-consumer site. This site has a partner that processes online car finance applications for them. Today this partner called and said he’d noticed our application volume was down, had taken a look at our application form, and it was asking for more info than they really needed. Perhaps, he suggested, if we streamlined the form and reduced the “friction” for our visitors, more people would complete the form? He pointed me to an example form on his own site.

I looked into it and, sure enough, our form had been created for a bank we no longer partner with, and all our remaining loan partners have less stringent requirements. We can in fact make it simpler for our users.

Granted … the call was motivated at least in part by the self-interest of the finance partner. They want more loan applications, so they can approve more loans, and make more money. But this guy seems to understand what eBay and its partners — PayPal and UPS — do not: that I will remember the pain of today’s experience with them long after I’ve forgotten the particulars. This will get filed in my brain under “don’t go there” and I will try very hard to avoid using eBay in the future, especially since I only have an occaisional need and no motivation to learn all the little warts and hiccups in their cranky little system.

All of this falls under the general heading of “usability”. Nothing about eBay, PayPal, UPS or my customer’s own loan application pages is exactly broken, in the sense that it works for most people most of the time, such that these companies are making money even while they are making enemies. But the user experience still sucks. In the case of my client, we just haven’t re-evaluated old code in awhile. In the case of eBay and Friends, it’s probable that there is a whole comedy of errors behind the glitches and frustrations I encountered. But in all these cases no one is regularly asking whether the user experience is smooth and as simple as it can be.

February 6, 2007

Project Estimation Made Plain

Filed under: Managment — Bob Grommes @ 5:38 am

Okay, I’ve tried to get this across in previous posts, but as usual, Bob Lewis says it much better than I could ever hope to. Read his post, and get wisdom!

For those in a hurry, the key paragraph is reproduced below:

  • Projects of any size and scope should always be about helping one or more parts of the business operate differently, not about delivering software that meets specifications. That being the case, the whole process of collecting software requirements from various stakeholders and reconciling it is bogus. Start the conversation by asking how the business should operate and everything about what follows changes. In particular, software requirements stop being a matter of finding compromises among various statements of “I want” and start being a simple account of the role software plays in new or changed business processes.

January 25, 2007

Scrum: Putting a Name on Intelligent Development Practice

Filed under: Managment,Methodologies — Bob Grommes @ 4:56 am

If I am pressed to come up with a methodology that is a somewhat close fit for my own thinking on how software development should be managed, it would be Scrum.

Scrum, for once, is not a clever acronym; instead it is slang for a group huddle in the game of Rugby, where the players cooperatively strategize about how to move the ball down the court. Although often used with Agile processes, Scrum actually has nothing inherently to do with Agile or eXtreme Programming — or even with software development, as it’s used in other fields of endeavor, too.

Scrum has been (mis)appropriated in various ways, including probably by me, but I like the general concepts.

First, Scrum recognizes a few uncomfortable facts of life:

  • Requirements are never fully understood at the start of a project. Even when you think they are.
  • Requirements (and your understanding of them) always change during a project.
  • The introduction of any new tools or techniques into a project renders it even less predictable.

Scrum is a way to manage projects with lots of unknowns — projects, such as software development, that need an empirical approach, not a fixed methodological approach.

You can find a pretty good 30,000 foot overview of the Scrum process here.

In essense, top management (or the project champion — whoever is the ultimate paying customer) conceives a project, chooses a team, and then gets the heck out of the way so they can do their job. This implies the first principle of Scrum, which is to trust and respect your team; after all, you picked them! This means that Scrum will never happen under a micro-managing, insecure, or abusive champion. The very idea of Scrum will terrify such a person. Managers who confuse leadership with browbeating or puppeteering, need not apply.

The product champion who initiates a Scrum project recognizes that it’s his or her job to support the team with resources. In almost all cases, the team will ask for the resources it needs; a good manager need not and generally should not offer to “help”.

Often, resource requests come in the form of reports of impediments to the project’s progress that require management authority to remove. In organizations of any size that have been around for any length of time, there are many well-intentioned procedures, processes and practices that do not serve effecient and effective software development. Product champions in a Scrum setting need to be prepared for the political chaos that can result from removing such impediments. That is why the champion needs sufficient authority (or at least real backing from higher management) to overcome these impediments.

More than one project I’ve been associated with has gone by the wayside when the progress of that project was at odds with the bureaucratic and political intertia of the organization; that is why you always need a champion with sufficient power to get obstacles removed. It’s like qualifying your lead in the realm of sales. There is no point in doing business with a champion with insufficient authority and clout.

I emphasize the management / sponsor / champion side of Scrum because it’s usually overlooked. The part that captures people’s attention seems to be the daily “scrum meeting” where everyone touches base about what they did yesterday and what they will do today. I personally consider this the least interesting aspect of scrum, as other than the daily frequency it’s a common-sense ritual of any methodology. But I suppose that organizations that don’t understand that meetings are productivity killers consider the scrum meeting to be profound because it’s only 15 minutes long. In addition, most organizations are meeting-addicted and don’t feel right about not having a meeting.

Scrum meetings are run by a “scrum master” who is responsible for making sure every developer answers three questions: what did you do yesterday, what will you do today, and what if anything is hindering you from your objectives? This strikes me as a little bit annoying and insulting unless done with considerable finesse; it could make the “scrum master” equivalent to the hated “hall monitor” (aka snitch) of grade school days. I wouldn’t formalize this role, but over time and on average, every team member does need to provide this info.

There is nothing about a scrum meeting that can’t be accomplished via something like a teleconference, IM, Groove, or even email. In fact it doesn’t necessarily require everyone to contribute at the same exact time, though it may well be convenient and logical to do it first thing every work day.

If I have a beef about scrum as it’s traditionally presented, it’s that it is a team sport metaphor that implies a team that is physically present in the same location on a daily basis. I am a believer in virtual teams, and cutting out the Amway-style back-slapping whoo-hoo yeah-team bullshit. For a good developer, doing insanely great work on an interesting project is all the motivation that’s required, and mutual respect of team members for each other’s technical capabilities is far more important than less relevant and less universally accessible bonding experiences such as a weekly game of tag football or meetings with free pizza.

The other key feature of scrum is the concept of “sprints”. A sprint is essentially focused work towards an agreed-upon monthly milestone. A lengthier, more formal monthly scrum meeting is used to present the work in progress. The goal of each sprint is to release a runnable, and as much as possible useful, version of the software under development.

From meeting to meeting, a list of backlogged work is kept — really just a prioritized to-do list; again, nothing profound here.

All of this is very common-sense and easy to understand. I like that sort of thing.

Like any Good Thing, scrum can be mis-used and abused. For example at http://www.controlchaos.com, a prime scrum promotion site, it’s suggested that you kick off a project by first setting the scope and deadline and then telling your team that they are charged with getting it done in half the time — and don’t be surprised if some people will even quit in protest. No kidding!

I reject that sort of arbitrary, manipulative crap. It contradicts other things that site says, such as that the objective is to do as good a job as possible. Any idiot knows that a deadline generated by marketing or just some dart thrown at a calendar is meaningless — things take as long as they take. Longer, in fact. Get over it.

Of course in the real world a project may be useful or valuable only if delivered before a certain date — in that case as long as everyone understands that the date is a constraint on what features and functionality can be implemented, that’s fine. Regardless of the underlying development methodology in use, scrum emphasizes delivering value in milestones at regular intervals (monthly is standard). It encourages discovery, design, implementation and QA in parallel.

So with scrum, what keeps the stakeholders happy is regular and open status meetings, plus early and frequent product deliveries and demos. That, plus the knowledge that people are hard at work doing their level best — whether or not the stakeholder had to compromise any on deadline or features.

December 27, 2006

Is Development a Science or an Art?

Filed under: Communication,Managment,Projects — Bob Grommes @ 2:10 pm

Let me say right up front that we’re not going to clear up the age-old argument between developers and bean-counters in this space. It’s been tried, over and over, since the beginning of the computer age.

Instead, I’ll just say that I think that, in the same way light has properties of both waves and particles, software development is both art and science. Indeed, in my view it’s a little more art than science. And I think that, just as there are very few true athiests in the world, there are very few people who would truly maintain that there is no art to development, and even fewer who would maintain there is no science to it.

Now that we have that out of the way I want to address the folly of going to the extreme of removing the craftsmanship from development and treating it as science.

Leaving aside my deeply-held suspicion that science isn’t going to save us anyway … that the image of dispassionate, relentlessly objective Men in White Lab Coats is a myth … let’s just say that there are powerful forces that want to make development into something that can be quantified, bottled, automated, commoditized, offshored, and in general made Predictable. These forces are well understood.

Historically every New Thing starts out as an arcane craft and is made one at a time, painstakingly. At some point, when its worth is proven, that product becomes standardized and commoditized so that it can be mass-produced, mass-affordable and more reliable (or at least Good Enough).

It is perfectly understandable that the world of business would hope that this paradigm could be applied to development. Especially since, tantalizingly, it appears that in some ways, it can be applied to development. For example, we can codify “best practices” and “naming standards”, and perform “static analysis”. We can use team development environments that enforce Corporate Standards — which can be either good or Stoopid, but let’s just assume they’re all good.

Even while conceding those points, though, there is a significant part of any non-trivial software development project that requires, not cold hard science, but passionate craftsmanship. And this is not just isolated to, say, the analysis phase of a project. It’s a thread that runs all through every part of the development life cycle.

Software develpment requires precious intellectual resources to be done right. Every day on a project, dozens of decisions must be made as to how to spend and apply those scarce resources. One must not only navigate the technical decisions, but the often conflicting and irrational political, regulatory, and marketing considerations which the project must effectively engage in order to be useful to anyone. And all of these factors are in constant and often chaotic change.

It’s tempting for non-developers and new developers to focus on the relatively easy stuff … the bare, obvious technical considerations, and assume that standard reductionist scientific thinking will eventually bring about predictable, reproducible results. But the truth is that organic, integrative, holistic thinking is needed, too. And that is the work of the mature craftsman.

This is happening in other fields of scientific endeavor as well, but it’s just easier to overlook. Historically, science’s hope was that by providing increasingly detailed understanding of natural processes we would come to fully understand them. But the fatal mistake was assuming that the universe is not infinitely intericate and complex, and that the same rules apply to the tiny picture (the sub-atomic level) as to the big picture (the cosmolocial level) and to everyday life at human scale. Science is increasingly running into trouble here. We have not found a hard limit to the size of the universe in either direction; we keep discovering annoying new dimensions we didn’t know existed; we keep encountering new rules that put previously accepted scientific fact to the lie.

It’s no different in the world of software development. You’ll never remove the need for the true craftsman. It takes someone who can deal with both the slippery, subjective, gut-level and human factors; it’s not just the technicians twiddling dials. And even the technicians should use Common Sense ™, which is not something that grows on trees.

The core skill of the software developer is correctly identifying and solving problems. Everything else is just execution. When software development projects are so often misbegotten and misdirected, we should not redouble our efforts to execute better. We should redouble our efforts to correctly understand the problem and the best points of leverage for addressing the problem.

Alas, accurate perception and accurate judgments about what to do with those perceptions, are not terribly amenable to Standard Processes. Knowledge and wisdom are two different things.

December 22, 2006

Playing a Game of Twenty Questions

Filed under: Managment — Bob Grommes @ 1:56 pm

In recent years it’s become fashionable to attempt to quantify the technical competence of developers using systems like exams (certification exams, basic competence exams, and so forth), gang interviewing techniques, and other formulaic methods. I ran across yet another list of interview questions today, and while it’s not a bad list by any means (and the author’s disclaimer that it’s more food for thought than an ironclad litmus test is also excellent), it does make me wonder if there isn’t a better system than this.

Most interviewers seem either unaware or unwilling to acknowledge that development has become a vast ocean of ever-churning platforms, components, libraries, add-ons, fashions and fancies. As such, it is virtually impossible for anyone to have an in-depth knowledge of every nook and cranny of even a single language much less a single platform.

So when someone wants to know what ports need to be open over a firewall for DCOM or to regurgitate, say, a variable locking pattern for thread-safe access, my reaction is, “I don’t know, and you shouldn’t care”. In the work I happen to do from day to day, I very seldom need those things, so I don’t clutter my brain with them. If I need them, I can Google them up in about 20 seconds and woof out a proof of concept in a few minutes.

What’s core to a good developer’s ability is not how many rote facts he can parrot on demand, but his analysis and problem-solving skills. Any developer thus equipped can suss out most any unfamiliar territory in very short order.

Yes, if your shop does a lot of work with, say, DCOM, then it’s a nice plus if a prospective new developer has deep experience with the technology. At the very least you ought to establish that the developer doesn’t fear it and has done work of similar difficulty and character before. But I would much rather have a developer with analytical common sense and seasoned general experience who doesn’t know much about DCOM beyond what the acronym stands for, than some wet behind the ears kid who happens to have cramed for the “exam” and knows some disconnected facts about it.

December 20, 2006

On Technology “Churn”

Filed under: Managment,Products — Bob Grommes @ 1:12 pm

Back in the days before dirt was invented — sometime in 2002 — Microsoft released version 1.0 of the .NET platform along with Visual Studio 2002. Among the technologies provided was an RPC stack called .NET Remoting, or Remoting for short.

Remoting was, like everything else in .NET, promoted like the Second Coming. It was the greatest thing since sliced bread.

I had a project that involved orchestrating a lot of data acquisition, conversion and scrubbing tasks on about a dozen PCs, and Remoting was absolutely the perfect solution. It worked absolutely great. The project was a complete success. With a little work, I had a complete workflow system with fabulous fault tolerance, even though one of the third-party applications called by each worker machine was notoriously temperamental.

Now that the project is “in the wild” it should serve my client well for the next dozen years or so.

Except for one problem: It’s obsolete already.

On a timeline that can only mean that Remoting was nothing but a stop-gap measure all along, Microsoft released a completely new and incompatible API for RPC work, the Windows Communication Framework, or WCF. Remoting is still in the .NET framework, and probably will be for the foreseeable future. But it has been sidelined and is now officially a Second Class Citizen. And all this happened in considerably less than four short years — two, if you count technology previews.

I’m not saying WCF is a Bad Thing. In fact, it looks like pretty good stuff. But consider what has happened here:

1. A small business invested scarce funds to produce a solution and expects (reasonably, I think) to get a return on that investment for many years with minimal additional costs.

2. Technically, they will get just that, but .NET developers who haven’t happened to work on Remoting in the past (including every new developer minted after about 2006) will know nothing about it. And likely, even those like myself who have experience with it, will be rusty. In addition, no new work will probably be done on Remoting by Microsoft, so if my client needs to integrate with future technology they may be forced to do a rewrite much sooner than they otherwise would have. If any bugs get introduced into Remoting, they are less likely to get caught and fixed quickly.. And so on.

Is this a big deal? Arguably, no. But it illustrates a fact of life that bullet-point-mongers in marketing seem to keep forgetting: no matter how great a given new technology is, the marketplace can only absorb it so fast.

There are limits to how many times per year a developer can retrain; actual work does occasionally have to get done.

There are also limits to how many platforms any developer can simultaneously be proficient at. It’s one thing if core functionality available in 2000 still works in 2006 and whatever has been bolted on since can be learned and leveraged as needed; it’s another thing if (as is the case with RPC) there’s been both a platform change and an API change in the same time frame.

Would I have handled this particular instance differently? Yes. In 2002 I would have given customers guidance about Remoting — that it was a stopgap technology and that a more comprehensive and flexible framework was under development for release three or four years hence. Then customers could make decisions and plans in the full light of reality rather than under the burden of marketing claims.

Of course, that’s never going to happen, but I can dream. I’d sure be nice if vendors were more respectful of the concept that when you provide a platform, it needs to provide a reasonable application life cycle for the things it supports. The lower level the platform, the longer that cycle needs to be. The only thing with a longer life cycle than an API would be the OS infrastructure itself.

This doesn’t mean the vendor can’t innovate within that framework, but they should consider it a personal failure if they have to needlessly pull the entire rug out from under customers. You might be forced to do that if, say, a competitor came up with something better and you had to match or surpass it to get the mindshare and momentum back in your court. But that’s making your problems your customer’s problems, which ultimately isn’t good business.

Sometimes when it comes to keeping up with technology churn like this, I feel like the Dutch boy with his fingers in the dike, trying to plug leak after leak. This isn’t because I’m old and set in my ways, or trying to Keep Everything the Same. I have, after all, willingly reinvented myself at least four times in my career, in the name of staying informed and competent. The transition from procedural to object-oriented development comes to mind, for example.

But there’s a balance to be had. There seems to be an ethos today that developers are somehow failing to Keep Up if they don’t attend, each week, at least one webcast about some vendor’s Latest and Greatest New Thing. Don’t believe it. Vendors just know we are suckers for new things, that’s all.

Instead of chasing every New Thing that comes along, prioritize relentlessly based on what you can get done for your clients effectively over time. Hint: this generally doesn’t have much to do with being on the Bleeding Edge 110% of the time.

December 17, 2006

Finding Meaning In Doomed Projects

Filed under: Managment,Projects — Bob Grommes @ 9:36 pm

Back in the late 90’s I was the primary, and often the only, developer of a fairly large project that I had the pleasure of being associated with from beginning to end. The software was the core product of a commercial credit bureau, and that product was desperately needed by grateful paying customers. In addition, no one else had ever done it before, and perhaps more gratifying, some have tried — and failed — since. The owners of that startup successfully cashed out, and I have that warm, fuzzy feeling deep down of having worked hard to produce something I’m very proud of.

Alas, such projects are extremely rare.

I’ve known developers who go through entire careers without having anything resembling the above experience. I was fortunate to be in the right place at the right time, and I know it.

Most projects, by contrast, suck in one or more significant ways.

A surprising number of them are actually, in some way, doomed.

In the “alternate reality field” that surrounds many businesses, software development projects are more often then not, created for the wrong reasons, to solve the wrong problems, in the wrong way. It’s one of the dirty little secrets that not only are most projects over budget, late, and wrong … but quite frankly, off target in the first place. You don’t read much about this problem for some reason. But I have a notion that a lot of those screwed up projects would manage to “gel” and produce something grand if everyone involved knew in their deepest soul that what they were doing was actually meaningful. Think about the projects you have the fondest memories of. I’ll bet not many of them were exercises in futility.

And so I come to the point of this essay: what do you do when you find yourself (as you inevitably and often will) in the midst of The Project That Will Never See the Light of Day, or The Project that Solves the Wrong Problem, or one of the other horrors of project management?

Well, there are some prerequisites:

  • Never, ever give a client bad advice. It’s true that their eyes will often glaze over and they will not follow your good advice. But, that is their choice. Never tell them what they want to hear. You can learn to do this without being needlessly confrontive. Sometimes both you and the client know their request for your input is only pro-forma; they’ve already made up their minds and don’t really want to be confused with facts. Go along with it … but make sure that no one can tell you, down the road, you didn’t tell them a better course. You’re a consultant, after all. Give good counsel. It’s the only way to build respect. Shoot straight!
  • Never accept abusive or exploitive situations, such as death march environments, a constant crisis atmosphere, lousy working conditions, insufficient tools, broken payment promises, etc.
  • Always confirm all agreements in writing. In practice this doesn’t generally need to be a contract, just a series of emails along the lines of “To confirm our conversation today about Project X …” You’ll be astounded at how seeing what they’ve just told you to do, in writing, and having it documented as their idea, can suddenly turn around an insane idea and bring it down to earth. But, if it doesn’t — you don’t hang for it later.

Assuming the above … you have a paying gig, a forewarned client, reasonable working conditions, and clearly agreed-to responsibilities. Now maybe the misbegotten project will not serve the client or employer; maybe it will ill serve them. But, you have a learning experience before you — a chance to make the architecture, the implementation, the realization the best it can possibly be. If it turns out that you created a pencil sharpener where a screwdriver was what was needed — so long as that’s what the client insisted on, despite your counsel — just make sure it’s a damn good pencil sharpener. A job well done is its own reward.

The sad fact of our craft is that most of our best work will be largely invisible to the world, even when the finsihed product is widely and successfully used. Most often no one will know how you jumped through rings of fire and ate little pieces of glass so that the transaction layer works correctly every time, and is fault-tolerant. But you know … and for most of us, most of the time, that has to be enough. If it’s not, you’re in the wrong line of work.

Create a free website or blog at WordPress.com.