Ever read an $8 e-book that changed your point of view completely?

Yeah, so did I, and I wrote about it today on my blog: The Manifesto vs. the Machine.

All of us in computer software development wrestle with "why is this undertaking so damned difficult?," and especially, "how can I convince my boss how we can make our jobs easier and our projects more successful?" This writer made the observation that, when we build software, we're actually building automatons ... a Mechanical Turk that actually(!) "plays chess" for our customers, and which must do so with not a single one of us nearby. We use sports terms like "rugby" and "scrum," but when our contrivances play and win or (usually) lose the game, we are in the locker room and cannot do one damn thing about what's happening out there on the playing field.

The little light-bulb blinked on. Stated in this way, it's not only "perfectly obvious," but it also says why writing software (robust software, anyway) is so hard. We're in the business(!) of playing "robot wars" in real life! But we fail to describe it that way when talking to our customers and management.

Hope you find it interesting.

Fortunately my days of mission critical software have largely gone away. I work in emulation of real time and fault tolerance doesn't exist. Things change so rapidly, and they want an app for that so very, very much, that what we really live in is a situation where the life cycle of the client's website or app becomes the issue. And the challenges are to churn it out fast enough so as to get the trial balloons flowing and the feedback, so that the next generation can be developed.

Doesn't mean that we don't wish to turn out good code either, it's just very undercut by the pace of customer demands.

I read $8, or higher cost EBOOK's, and always think that the paperback variation is cheaper and that sort of makes me mad. However I pay and try not to grumble.

Agreed. No chance of me paying $8 for an ebook that would be a $4.99 softback. I like the convenience of ebooks, but not enough to pay more for it than a real book. I'll wait until they release the paperback to read this. Or drop the price to an acceptable level for ebooks.

Hmm... I never thought myself ill-used by one price-point versus another. (But, did I just get ripped off ... to the tune of four bucks?)

(I know the guy ... "if he dropped his price ...?")

Maybe my own bias shows up my praise: "I don't do web sites." Never have, at least not public-facing ones (with one exception, for which I was just a participant). The unmistakable and un-eraseable public perception of any web-site is that it must cost them nothing. Hence, the costs of developing and maintaining such sites are just "cost of goods sold," or, worse yet, "advertising expense," because not one of the however-many thousand or millions of "eyeballs" paid even one thin dime of revenue in exchange for the very-dubious privilege of being counted as "an eyeball."

Per contra, if the application is only used internally, whether-or-not it is built using "web" technologies (as, these days, it ordinarily is ...), it is "part of the Core, Revenue-Producing Business."

Therefore, throughout my career, I have focused on helping projects that were "inside" the client companies. (I never wanted to have to deal with "The Marketing Department" as a source of project funding, partly because "Marketing" can only command the discretionary part of the Budget.)

But also: I've been called-in to help rescue(!) those projects when they were veering wildly off-course into The Land of Broken Promises. I kept finding people standing around white-boards full of sticky notes, who never realized that what they were doing cost somebody-else real money. (They just took "the money" for granted, because they were the ones receiving it. "Ahem ... at that time.")

Yeah the apps are in a sense "overhead" and everyone should be able to download it for free and use it. But they fail to think the two or three things which are (1) the storyboard does need to be done, otherwise the most influential person in the meetings (CEO, VP, etc) wins, but also can dramatically affect the outcome, good/bad/otherwise, (2) yeah it's gonna cost development time even if the result is free. In this, Apple's approval process for an app actually helps because suddenly the client realizes, "Hey, yeah, it DOES need to be tested..."

Unfortunately I have no magic wand. We do stuff all the time, they "love" it, and then they want to change it entirely. Then they "love" the next one. All you can do is write a spec, describe how it's going to work, state that it is the deliverable, give them their final chance at modification, develop it per the spec, then await their next "what if" moment.

And, as long as they pay each and every time for "their uncertainty," I'm absolutely cool with that.

As long as, each and every time, the product they want to change is "rock solid."

In other words, if the customer can't make up his mind, but he's got the money to pay for the fact that he can't make up his mind, "that's not my problem ... that's just business."

The situation that I am normally called-in to ... ahem ... "address" ... is when the team can't deliver. When they "can't make up their mind" as to what's supposed to be delivered, and/or when they can't deliver it.

Sometimes, the two situations work against one another, and the development team didn't have the presence-of-mind to compel the other party to "a contract." Ergo, two "moving targets" are bouncing against each other and nothing is sticking to the wall. (Often, it turns out that the development team wasn't listening to the right authority ... namely, the department that is paying the bill.) The developers never manage to deliver what their perceived-customer never managed to decide upon. Eventually, some other party steps in, says to the developers, "show me what you've got, and show me that it's working, now."

. . . And-d-d-d . . . they can't do it, and they get fired (with one or more invoices unpaid), and . . . I get called in.

Very interesting read, thanks for sharing.

Philip