The Eternal Struggle Between Business and Programmers

The Business and the Programmers want the same thing. They want the same thing: to deliver a more predictable stream of important features that will make the market happy—or, at least, knowing the fickle market, that will risk disappointing them the least.

This. Is. Glorious.

The Business and the Programmers needs to agree on two things, each conceding a key point to the other. The Business needs to agree that the Programmers have heretofore gone more quickly than they really can, that they cannot sustain this pace, and that to do so merely hastens the ultimate decline of the entire product line, and perhaps the company. The Programmers need to agree that the Business has a legitimate need to deliver more features, that everyone’s livelihood depends on this, and that trying to ask for more than the Programmers can deliver forms part of the Business’s “job”, as it were. The market compels them to do this. In this equation, the Programmers have the responsibility to do whatever they can to maximise their ongoing delivery speed, and that includes regular, agreessive refactoring.

Finally, both the Business and the Programmers have to agree that they have wasted too much time arguing about this and need to move forward. They want the same thing! They can have it!

via The Eternal Struggle Between Business and Programmers – The Code Whisperer.

If you respect a [developer], you talk about the [code]; if not, you psychoanalyze the [developer].

… if you respect a writer, then you talk about the work. If you disdain the writer, then you try to psychoanalyze the writer and figure out why would he write this. … If they mention my work at all, which they rarely do, it’s to dismiss it and to psychoanalyze me, which they are incapable of doing … They have no idea what I’m talking about.

A lot of criticism is like, including project criticism. Via Critics, community and ‘Ender’s Game’: An interview with Orson Scott Card | Deseret News.

Quality, Features, and Schedule

From the book Lost Moon, retitled Apollo 13 after the movie was made:

Apollo was downright dangerous. Earlier in the development and testing of the craft, the nozzle of the ship’s giant engine…shattered like a teacup when engineers tried to fire it. During a splashdown test, the heat shield of the craft had split open, causing the command module to sink like a $35 million anvil to the bottom of a factory test pool. The environmental control system had already logged 200 individual failures the spacecraft as a whole had accumulated roughly 20,000.

In January 1967, one of the first Apollo spacecraft caught fire during an on-the-ground test, killing astronauts Gus Grissom, Ed White, and Roger Chaffee. At that point, NASA decided that quality was more important than schedule and they overhauled the Apollo project (although they still managed a moon landing 2-1/2 years later).

Far too many software projects are like that. It usually takes a serious failure, one where blame cannot be shifted, for managers to realize that their schedule is unrealistic. Via Quality, Features, and Schedule | askblog.

20 Rules of Software Consulting

Ask Not What’s Possible: the question is not what you can do, the question is how much the client is willing to pay for it and how long they will wait.

Time Substitutes for Money on a Logarithmic Scale: e.g cutting the time by 20% will require doubling the budget. Cutting the budget by 30% will quadruple the amount of time.

All Estimates are Optimistic: new application development will take three times as long as you expect, and cost twice as much. Or vice-versa.

(Emphasis in original.) Via Database Soup: 20 Rules of Software Consulting.

“Planning” and “Doing” In Software Development: A Lesson For Product Managers

Taylor confused the logical proposition that planning and doing are distinct functions with the empirical claim that these two functions are always best performed by two distinct classes of people endowed with distinct educational pedigrees, clothing styles, and patterns of speech. The one is nonfalsifiable; the other is simply false. Cutting up your food and eating it are distinct functions too, but it is not the case that they are always best performed by two different people. In manufacturing businesses, separateing planner from doers sometimes makes sense; but, as Japanese carmakers proved to the dismay of their American rivals, getting the doers involved in the planning can result in higher-quality products and lower costs.

— Matthew Stewart, “The Management Myth”, p 55-56

I see a lesson here for software product managers: if you get the developers involved in the product planning process, you may end up with higher-quality products. The developers are not mere tools that serve the ends of your planning process; they can be very useful in helping you devise and define that product, espeically since they are the ones that have to actually build the thing.

Efficiency vs Quality in Software Development

Implicit in Taylor’s approach is the idea that management always aims at the single goal of effciency (understood as labor productivity). But efficiency is just one of several possible competing goals that management might pursue. Profitability, customer satisfaction, or maintaining good community relations can always conceivably outweigh the goal of efficiency. Later management theorists have argued that Taylor’s obsession with efficiency came at the expense of the goal of quality.

— Matthew Stewart, “The Management Myth,” p 54

I cannot help but read that paragraph and think of software development practices. We want efficiency of algorithms, but the quality of the code (understood as its comprehensibility and maintainability by other programmers) is an equally important goal.

The dark craft of engineering management

Why is management a craft?

It’s a craft for the same reasons engineering is a craft.  You can read all the books you want on something but crafts are learned by getting your hands in it and getting them dirty.  Crafts have rough edges, and shortcuts, and rules of thumb, and things that are held together with duct tape.  The product of craft is something useful and pleasing.

via tech ramblings » Blog Archive » The dark craft of engineering management.

Jones’ Law

While working on my Daycamp for Developers presentation, I’ve been going through some of the “laws” related to project management and estimation: Brooks’ Law, Hofstadter’s Law, and others. As part of this, I’ve decided to coin my own; it’s something I’ve been saying for at least a decade:

Jones’ Law: “If you plan for the worst, then all surprises are good surprises.”

Attend Daycamp for Developers and you can hear more about estimating software projects and setting client expectations, as well as lots of other “soft” topics that developers can benefit from.

On War, and Development

… It is not, in the modern world, enough to be a lone visionary.  Under modern conditions, strategic genius must necessarily be linked with bureaucracy.  The greatest genius needs a military machine and a state structure.  More, as Henry Kissinger discovered to his frustration, a hostile bureaucracy can frustrate and sabotage a brilliant leader’s initiatives in many ways.  Commands given by a great general or initiatives envisioned by a great diplomat must under modern conditions be executed by great throngs of non-genius employees and functionaries.  There is no other way.

Remember this: your idea has to be executed by people who do not necessarily share the entire scope of your vision. Via Clausewitz: Master of War | Via Meadia.

Blogger outage makes case against cloud-only

Earlier this week, Google rolled out a maintenance release for its Blogger service. Something went terribly wrong, and its Blogger customers have been locked out of their accounts for more than a day. Google’s engineers have been frantically working to restore service ever since, although they haven’t shared any details about the problem.

That’s nearly 48 hours of downtime, and counting. Overnight updates promise “We’re making progress” and “We expect everything to be back to normal soon.”

Google has owned and operated Blogger since 2003. It’s not like they’re still trying to figure out how to integrate the service into their operation. If it can happen at Blogger, why can’t it happen with another Google service?

This, to me, is the strongest possible argument against putting everything you own in the cloud. If your data matters, you need a hybrid strategy, with local storage and local content creation and editing tools. If your local storage fails, you can grab what you need from the cloud. If your cloud service fails, you’ve still got it locally. But if you rely just on the cloud, you’re vulnerable to exactly this sort of failure.

via Google’s Blogger outage makes the case against a cloud-only strategy | ZDNet.