By

2 Comments

IT and baseball: no silver heuristics

Along the lines of my last post that discussed avoiding slogans and “lazy thinking” in IT, let’s talk about the increasingly popular word “heuristic”. I think we can all agree that developing software is anything but simplistic. So why aren’t we more skeptical when people propose adopting simplistic heuristics for developing software? Let’s look more closely at this manner of thinking, with a specific example.

In a recent exchange, a #NoEstimates advocate declared that one example of someone making a decision amidst uncertainty, without estimating, was the act of catching a fly ball. My response was that there are in fact many estimates involved in that activity, whereupon the #NoEstimates advocate put forth essentially the notion that a fielder uses the following heuristic instead:

“One good way to catch a fly ball is to hold up your gloved hand at a constant angle, and run so that the falling fly ball is directly aligned with your glove. If the fly ball appears above your glove, it is going to go over your head: move back. If it appears below your glove, it is going to fall in front of you: move forward. Left of glove: move left. Right: move right.”

But really: watch any major league baseball game and look for a single instance, just one, where the outfielder is doing anything even vaguely resembling the above. (However, one can certainly conjure up the specter of hapless Little Leaguers, coached in this #NoEstimates heuristic-driven technique, desperately waving their gloves back and forth in front of their faces, flinching while fly balls thud to the ground all around them). You won’t find a real-world example of the above-described heuristic, because using just that heuristic will not lead you to predictable success in catching most fly balls. [Read more…]

Filed Under: Estimating, General, Industry trends, Process Tagged With: , , , , ,
By

Leave a Comment

Lazy thinking: IT shibboleths, sloganeering, and sacred cows

At one company I worked, the executive team had come up with a list of core corporate values. There were 11 of these values, and they were mentioned and pushed in every company meeting.

In fact, “Goals and Values” wallet cards were handed out to each employee.  And let me make sure I affirm one important thing here, prior to what I’m about to say: these were, without a doubt, very worthwhile values: “Stay close to our customers”, “pursue excellence in all we do”, and so on. Note that I still carry this wallet card with me today, two decades later.

But here’s the thing: the values, despite all their great qualities, became cliches, overused, cited on every conceivable occasion and for every possible purpose. I remember the company president at the time: he even roamed the halls every once in a while, popping his head into random conference rooms, barking one or more of the company values at the nonplussed attendees: “Well? Are we staying close to the customer?” And in almost every meeting, people would spend substantial time itemizing earnestly how well a proposal fit in with the values, sometimes more than the time they spent explaining the actual pros and cons of the proposal itself.

Here’s where I’m going with this (and do hang in there for the connection I’ll draw specifically to IT): easy references to the goals and values became for many a substitute for actual thinking. And substitutes for actual thinking are seductive and rife.  But alas, good ideas and concepts, even when innately wise and useful, can turn counterproductive when simply used de rigueur and without thinking. Most insidiously: they can be used to justify what you want or don’t want to do anyway, often for reasons you can’t or won’t state transparently. [Read more…]

Filed Under: Anecdotes, General, Industry trends
By

9 Comments

IT extremism strikes again: the odd resistance to bug tracking

In information technology and software development, how many of our wounds are self-inflicted?

Here’s what I mean.

What I’ve seen happen, recurringly, in IT over the years and decades: idealistic but inexperienced people come along (within IT itself or in other departments within a company), to whom IT systems and issues seem to be easier than they in fact are. They are smart and earnest and oh-so-self-assured, but they also seem blissfully unburdened by much real understanding of past approaches.

https://twitter.com/CompSciFact/status/602271417330225153

They are dismissive of the need for much (if any) rigor. They generalize often quite broadly from very limited experience. Most notably, they fail to understand that what may be effective for an individual or even a small group of developers often doesn’t translate into working well for a team of any size. And, alas, there’s usually a whole host of consultants, book authors, and conference presenters who are willing and eager to feed their idealistic simplifications.

Over the years, I’ve seen a subset of developers in particular argue vehemently against any number of prudent and long-accepted IT practices: variously, things like source code control, scripted builds, reuse of code, and many others. (Oh, yes, and the use of estimates. Or, planning in general.) To be sure: it’s not just developers; we see seasoned industry analysts, for reputable firms, actually proposing that to get better quality, you need to “fire your QA team.” And actually getting applauded by many for “out of the box thinking.” Self-inflicted wounds.

But let’s talk about just one of these “throw out the long-used practice” memes that pops up regularly: dismissing the value of bug tracking.

How can anyone argue against tracking bugs? Unbelievably, they do, and vigorously.

A number of years back, I came into a struggling social networking company as their first CTO. Among other issues, I discovered that the dev team had basically stopped tracking bugs a year or two before, and were proud of that. Did that mean their software had no bugs? Not when I talked to the business stakeholders, who lamented that nearly every system was already bug-riddled, and getting worse by the release.

Why did the development team shun bug tracking? That wasn’t quite so clear.

[Read more…]

Filed Under: Anecdotes, Industry trends, Process, Tools Tagged With: , , , , , ,
By

Leave a Comment

The CIO and integrity: this shouldn’t be hard, folks

Surprising and disturbing IT-related news crossed my Twitter feed last night: a well-known CIO is being sued for alleged fraud by his former firm. Allegations are that this senior executive received kickbacks from vendors that he helped connect to the company where he served as CIO and vice president.

My purpose here isn’t to comment on this individual case; it’s now in the courts, information is still sketchy about the details, and I feel that people are entitled to a presumption of innocence while the various legal actions run their course. As Forbes columnist Ben Kepes wrote, though, this is “one for the ‘we knew these things happened but tried not to know about it’ department.” Update as of December, 2021: a conviction and sentencing in the courts).

So let’s broaden the topic to the overall issue of CIO ethics and integrity, particularly with respect to financial matters. As I’ve written before, the head of technology for many companies (certainly all the firms I’ve worked for) stands at the rudder of a very large portion of the overall “spend” for that company. IT infrastructure and systems spending, taken broadly, is often the second-highest category, after salaries, for total annual outlay for a company. The responsibility involved for the senior IT executive cannot be overstated.

HT @marciamarcia

Often when I’ve come into a new CTO/CIO position, I’ve discovered, over the course of the natural “archaeology” that one performs in such a situation, highly questionable business deals cut by my predecessors with outside vendors. I’ve raised my eyebrows and, yes, even occasionally shouted a bit at the incomprehensibility of various vendor arrangements I’ve inherited.

[Read more…]

Filed Under: Ethics, General, Industry trends, Role definition Tagged With: , , , ,
By

2 Comments

The case against #NoEstimates: the bottom line

I’ve now methodically presented the case against #NoEstimates in three different lights: from a common sense standpoint, from the perspective of the solid reasons why estimates are useful, and by examining the various frequent talking points used by NoEstimates advocates.  Looked at from any of these angles, NoEstimates comes up way short on both its core ideas and business practicality.

Aside from these issues of substance, let’s look briefly at the behavior of the NoEstimates proponents. Blunt as it may be, here’s my summary of the behaviors I’ve seen across most NoEstimates posts and tweets:

  • Presenting, and repeating via redundant tweets month after month, fallacy-riddled arguments consisting primarily of anecdotal horror stories, jibes at evil management, snide cartoons, and vague declarations that “there are better ways.”
  • Providing little or no detail or concrete proposals on their approach; relying (for literally years now) on stating that “we’re just exploring” or “there are better ways”
  • Consistently dodging substantive engagement with critics, and at times openly questioning whether critics should even have a voice in the discussion. If NoEstimates avoids engaging actively in the marketplace of ideas and debate, why should their arguments be taken seriously? Real progress in understanding any controversial topic requires we do more than state and restate our own views, but actually engage with those who disagree.
  • Continuing to use discredited examples and statistics, or even blatant misrepresentation of the stated views of recognized authorities, to help “prove” their case.
  • Frequent use of epithets to describe NoEstimates critics: “trolls”, liars, “morons”, “box of rocks”, and more.

I pointed out in my introduction that the lofty claims of the NoEstimates movement (essentially, that software development can and should be an exception to the natural, useful, and pervasive use of estimates in every other walk of life) carry a heavy burden of proof. Not only have they failed to meet that burden, they’ve barely attempted to, at least not the way that most people normally set about justifying a specific stance on anything.

But aside from style, let’s return to the substance of the issue. Here’s my take, as backed by specific examples over the course of these blog posts: estimates are an important part of the process of collaboratively setting reasonable targets, goals, commitments. Indeed, whether estimates are explicit or implicit, they’re a reality. I see them as an unavoidable and indispensable factor in business.

[Read more…]

Filed Under: Estimating, General, Industry trends, Process Tagged With: , , , , , , ,
By

7 Comments

The case against #NoEstimates, part 3: NoEstimates arguments and their weaknesses

I’ve spent the last two blog posts introducing the #NoEstimates movement, first discussing what it appears to espouse, and presenting some initial reasons why I reject it. I then covered the many solid reasons why it makes sense to use estimates in software development.

This time, let’s go through, in detail, the various arguments put forward commonly by the NoEstimates advocates in their opposition to estimates and in their explanation of their approach. Full disclosure: I’ve attempted to include the major NoEstimates arguments, but this won’t be a balanced presentation by any means; I find these arguments all seriously flawed, and I’ll explain why in each case.

Here we go, point by point:

  • “Estimates aren’t accurate, and can’t be established with certainty”

Let’s use Ron Jeffries’ statement as an example of this stance:

“Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. “

But “accurate” is simply the wrong standard to apply to estimates. It’d be great if they could be totally accurate, but it should be understood at all times that by nature they probably are not. They are merely a team’s best shot, using the best knowledge available at the time, and they’re used to establish an initial meaningful plan that can be monitored and adjusted moving forward. They’re a tool, not an outcome. As such, the benefits of estimates, and their contributions to the planning and tracking process, exist even without them being strictly “accurate” per se. These benefits were itemized in my last post.

Knowing the future precisely isn’t what estimating is about, actually. It’s a misunderstanding and a disservice to think it is. Here’s why. [Read more…]

Filed Under: Estimating, General, Industry trends, Process Tagged With: , , , , , , , ,
By

5 Comments

The case against #NoEstimates, part 2: why estimates matter

Last time, I provided an introduction to a very odd and very vocal recent movement known as #NoEstimates, which seeks ways to reduce or eliminate the use of estimates in software development. I started off my discussion of it by going through some basic common-sense business reasons to reject it. Those reasons for rejection boiled down to:

  • estimates are flat-out natural, ubiquitous, and unavoidable in practical life and in business;
  • expressing general reluctance to do them unfortunately reinforces the often negative perception of IT people as aloof, uncooperative, and unsavvy about business imperatives.

Let’s look now at the many other solid reasons to keep estimates in the software development and project management toolbox:

Estimates help in project selection over a wider time frame, and they assist in filling in a project portfolio evenly to align with overall team/company capacity. Specifically: companies often need to determine which projects to sink time and company resources into: e.g., needing to pick just three out of a list of fifteen proposed projects for a given time period. This is a common and recurring dilemma in every company I’ve ever worked at, where demand for various business functionality always exceeds the supply of resources to fulfill it.

In such a ubiquitous scenario, what makes anyone think that the anticipated cost and duration for delivering each potential project should not figure into the decision process that selects the “vital few” from among the many choices? Why would you possibly rule out considering those factors to the best of your ability? Yes, of course they should be weighed along with value, risk, and other factors, but cost and schedule will always be among the key considerations to juggle.

You’re thinking that assessing probable cost and schedule can’t be done, because you’re uncomfortable with uncertainty, and perhaps you might get it wrong? I’m going to be blunt: then you’re not ready to play strategically in the business arena.

Estimates reduce overreliance on experimenting with “red herring” projects. Nothing is wrong with selective and judicious experimentation on a small scale, focused on learning and adjusting, but the universal NoEstimates answer to the project selection conundrum is to “just start”. Well, simply as a practical matter, you can’t “just start” 15 different projects as an experiment and gather enough useful, consistent information on all of them to feed into your decision meaningfully. Even if you could and did, you’d still have to use your gut (i.e., you’d have to estimate) based on what that information is telling you, since very few of the unknowns associated with each of the potential projects would have been eliminated via the short experiment. The NoEstimates panacea of “story slicing” doesn’t help you here at this up-front stage: unless (and even if!) you story-slice the entire project (which would be BDUF), unknowns will almost certainly continue to lurk in your backlog, some big, some small.

There’s simply no way around it: at some point, if you want to choose purposefully among competing options of similar value, you have to take a shot at determining what each project is likely to take (cost, schedule, dependencies), despite imperfect information.

You don’t like it that there’s a possibility that you might get it wrong and pick the “wrong” projects? Bluntly, again: then you’re not ready to play strategically in the business arena. [Read more…]

Filed Under: Estimating, Industry trends, Process
By

3 Comments

The case against #NoEstimates, part 1: introduction and common sense

In the immortal words of Pogo, “we have met the enemy, and he is us.”

The long-held stereotype of IT portrays us as uncooperative, unable to integrate socially, always arguing over nits, and deeply, intractably immersed in our own tunnel vision and parochial perspective.

That stereotype has held us back, as individuals and as a profession: it’s actually one root cause for the oft-lamented situation of the CIO needing a seat at the executive table and not getting it.

Now a whole movement has arisen that unfortunately reinforces that negative perception of IT people, a movement that coalesces around the Twitter hashtag #NoEstimates (all movements need a Twitter hashtag now, it appears). It started with long screeds about how inaccurate estimates are for software development: they’re nothing more than guesses; “there is nothing about them that makes them necessary, or even beneficial to the actual creation of software”. They’re a “wasteful and deceptive practice“, lies, and needing them is even comparable to how heroin users need their heroin. You can’t predict the future, these estimate detractors insist. The #NoEstimates rhetoric has become increasingly harsh, and replete with drastic imagery: estimates are a “game of fools“; an “inherited disease for the industry“; “we predict like gypsy ladies.” In what seems at times to be some kind of “top the previous hyperbole” competition, estimates have even been referred to as “management by violence”.

This sort of overreaction, this IT resistance to estimates, isn’t really wholly new, of course. More than once, I’ve watched in horror as an IT person earnestly explained to a company’s senior management how predicting systems delivery is so very difficult and so very filled with uncertainty, justifying how (for example) they couldn’t possibly commit to having a system deployed in a particular quarter. One time, I witnessed the VP of Sales in particular having zero patience with that: “Hey, I get asked to set my sales quotas way in advance based on my best professional judgment; what makes you folks in IT think that you should be an exception?” Business runs on goals and commitments, and on the “best judgment” estimates that help create those goals and commitments. And everyone in the room seems to understand that, except IT.

Setting achievable, concrete goals is healthy, in business and in life. Making solid, reasonable commitments is healthy. Taking responsibility for meeting one’s commitments all or at least most of the time is natural and should be encouraged. And if you’re perceived as constantly wailing that you’re different and special, in fact so special that you believe you can’t really be expected to state when you’ll be done? That’s a non-starter. This blog post is an introduction to how some IT practitioners have been pulled in by the seductive but ultimately wrongheaded NoEstimates claims, and what the resulting implications are for our industry.

What’s #NoEstimates about? Well, its proponents are actually quite slippery on providing any solid definition, reflexively pushing back whenever anyone tries to summarize it for them, and they often prefer to vaguely say it’s just “a hashtag for a concept about alternatives to estimates and how they might help make better decisions.” However, it seems to boil down to a virulent and unshakable base conviction that estimates are utterly horrible, for all the reasons stated above and more. Using estimates allegedly leads to chronic abuse of developers by management, cements inflexibility into projects, and disturbs developer “flow”. The sole alternative to estimates that the NoEstimates advocates clearly identify, however, seems to simply restate the age-old Agile principles of small teams, user stories sliced into doable chunks, use of “drip funding” so as to achieve a predictable fixed cost, and software delivery “early and often”. They point out that software project scope tends to change drastically and frequently during such frequent delivery, and argue that this scope variability allows projects to be declared as done and successful, long before and without ever having actually delivered all the upfront-identified desired functionality.

Over the next two blog posts, I’ll first lay out the reasons to see considerable value in a software development estimating process and its outcomes, and then respond to the myriad NoEstimates complaints that are levied against estimates as used for software development. But we’ll start here, as an intro, just with invoking basic common sense about life and business.

[Read more…]

Filed Under: Estimating, General, Industry trends, Process, Stakeholders, Top 25 posts
Mastodon