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.

January 19, 2007

Software — Cheap!

Filed under: Methodologies,Projects,Tools — Bob Grommes @ 8:27 pm

Once in awhile, for entertainment, I visit online freelance software development exchanges. It’s a fascinating study of the endless human capacity for witless self-deception. I actually saw a posting today from a guy who wants someone to clone an entire accounting system. Other than the name of the system to be cloned and an unexplained desire to have the work done in PHP, that’s the entire specification. And the budget? Two hundred dollars. I kid you not.

Apparently this guy thinks there are people who can knock out an entire accounting system in two hours. Okay, maybe he’s thinking twenty hours with third world labor. But still.

Apparently his reasoning process goes something like this: (1) I can buy Quicken for $79, therefore (2) it will cost a LOT more than $79 to write my own clone of Quicken — maybe as much as three times as much, but (3) I’ll cut it down to an even $200 as a starting point for negotiations.

I recall a couple of years ago getting a contract pitched to me where the objective was essentially to clone the whole Google search engine. The guy seriously believed that I could lead a team of a half dozen others and pull off in six months what Google, a company with thousands of employees, has spent a decade building. We would all work for fifty grand a year but in six months we’d go public and we’d all be millionaires. Hooray for us!

This guy got my award for Most Improbable Personal Delusion of the Year, until a scant week later I saw a very similar posting to a freelance site with a budget of $500!

There are literally hundreds of such postings floating around the Internet at any moment in time. It makes me wonder if these boards exist for no purpose other than to fleece the simple minded. What kind of contractor would respond to such a post? It must be the sort who will take a one-third deposit up front and then disappear.

What disturbs me most about all this is that while it represents an extreme, it seems to reflect that the commoditization of the craft of software development has reached some kind of fever pitch. I turn down many projects that come my way, for the simple reason that the customer has totally unrealistic expectations. Thankfully no one has yet asked me to write an accounting system or a major public web site or a spacecraft control system in one afternoon for under a hundred dollars — yet — but sometimes it seems like things are heading that way.

What this tells me is that the average person no longer values software. We are used to freeware, shareware, open source, and sub-$100 list prices for commercial software. The gargantuan size of the software market hides the gargantuan effort and expense that went into developing all those general-purpose software products.

Additionally, software development remains a painful and challenging process with many pitfalls for the unwary, and it just doesn’t deliver the effortless and instantaneous results we’ve come to demand of every aspect of life. People will jump through rings of fire and eat little pieces of glass before they will make allowances in their business plans for the fact that the mission-critical software they need will take six months and a couple hundred thousand to put together. “Screw it … we’ll use Excel!” they say.

So … what’s the deal? Is software a commodity now? Can we really put together complex systems in minutes from off-the-shelf components with no planning or testing?

According to a recent profile in Technology Review, no less a person than uber-programmer Charles Simonyi (the guy who was once the driving force behind Microsoft Word) plans to give the public what they are clamoring for. He is on a multi-year quest to create something he calls “intentional software”.

The over-simplified summary of what Simonyi wants to create is: “an expert system that will allow non-programmers to put together software specifications.” Then, by pushing a button, all the code will be generated to produce complex applications that fulfill those specifications.

I’ll concede that I probably don’t appear to be the best candidate to be impartial about the feasibility of Charles’ dream. Still, I doff me hat to ‘im, and wish ‘im well, I do. Because if he actually pulls it off, we will be living in a world of luxury and abundance and riding the wave of another “dot boom” and I will find a way to prosper from it, as will you, gentle reader.

However, my personal prediction is that what will come out of it, is something akin to Charles’ original brainchild, the graphical / WYSIWYG word processor. By which I mean that it will be something we will all take for granted and wonder how we could possibly live without, but it will also fall short in ways that will annoy the living bejesus out of us. (In the above referenced article there is a priceless vignette where Charles’ PowerPoint presentation hangs and the much-hated Clippy the paper clip pops up to offer useless advice. Charles confesses ruefully to the interviewer that even he has no idea how to disable the blasted thing).

Why do I think Charles will fall short of his lofty goal?

One of the reasons is well presented in a sidebar to that article in Technology Review, and that is generically known as the “leaky abstraction problem”.

At a more fundamental level, Charles’ earnest vision depends on reductionism, the idea that every problem can be solved if you can break it down far enough. This is an understandable stance for a software developer, as much of what we do involves breaking large problems down into smaller sub-problems and then putting it all back together. But it has its limitations. When developing software, you are ultimately solving problems that involve “wetware” (people) and that is inherently subjective and messy and chaotic. At some point that interferes with doing science and you have to make very subjective judgments to find a way forward. No development methodology or tool will ever fully automate those judgments.

Now I’m going to say something provocative and easily misunderstood: most of the world’s business is conducted by small to medium-sized companies. Most custom development needed by such companies are relatively modest compared to an enterprise-scale “Manhattan project”. In almost every case, by the time you’ve adequately spec’d most of these projects, you have finished implementing them. It is literally a case of “we’ll know when we are done”. I know this will make the Agile folks, the bean counters, and others apoplectic, but it’s the truth. Anyone who tries to paper it over is just patronizing you.

Software development is an iterative process of discovery. It’s done when it’s done. If you have a big enough project you can do proof-of concept “mini” implementations of various things, run simulations, conduct focus groups, have committee meetings and fill out ISO forms to your heart’s content. And then maybe, assuming all the stakeholders have been honest and diligent (a huge assumption), you will be able to come up with a reasonably close cost estimate / budget.

But in a smaller setting the grim reality is, you’ve got a champion with a fairly vague idea of what they want — more of a vision than a spec — which is communicated in glowing terms to someone like me, who does their best to ask pertinent questions and classify the project as a one, three, six or twelve month project times X number of developers. As the project rolls on the champion has a thousand suggestions for changes, the actual users inform you that for various reasons certain aspects of the vision are completely unrealistic, certain others decide they want the project to fail and employ passive-aggressive tactics to bring that about … and in the end, you have something that is not really what anyone expected up front, in terms of its final form or its cost, other than in very general terms, such as, for instance, “an online credit bureau for trucking companies”. Which comes to think of it, sounds suspiciously like the tiny postings on those freelance boards.

What the online freelance exchanges represent is the earnest desire of many to be able to express a complex system in one sentence, pay a tiny, nay, microscopic fixed amount of money and have it appear magically in a few days or even hours (another common subtext in these postings is “I’ve known about this for two months but just remembered that the deadline is tomorrow”).

Listen to me carefully: IT ISN’T. GOING. TO HAPPEN.

What Charles Simonyi’s more refined vision represents is the understanding that you can’t express complex systems in one sentence. But he still labors under the belief that with the right tools you could express it in terms that people who know nothing about software architecture could comprehend, in ways that will reproducibly result in relatively fast, easy implementations that are also accurate. This, I don’t think is going to happen either, at least not in my lifetime. I strongly suspect it’s a reductionist fantasy.

Check back in fifteen or twenty years and we’ll see!

Update: For more on this popular topic, please refer to the follow up post.

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

Blog at