A Tale of an Under-Resourced Project

Myrmidon Inc Part 1

dam was feeling the pressure. 12 months ago he was given a large project (Project Beowulf) and it was still no where near being complete. Carla his manager once removed had made a nasty remark about the time taken making it sound like Project Beowulf was the only project he was working on. Adam had repeatedly been pulled off Beowulf to work on higher priority projects.

In response to pressure from Carla (the product manager) , David (Adam's manager) assigned Ethan (a more experienced programmer) to help him. Ethan was told to complete some of the features that were part of Project Beowulf. Ethan reviewed Adam's work and made some design suggestions that he thought if implemented would make it easier for Adam to complete the project. He also identified several sections of duplicate code that if extracted into their own classes could be used for some of the uncompleted features.

Then Ethan found the real problem. Beowulf was supposed to work with Module Grendel. Grendel not have a well designed API. In fact it did not have a API at all. You just found a section of code that did something similar and copied that. Grendel was written by David under intense time pressure and David was considered a Hero for finishing Grendel.

Even though the Interface with Grendel was only a small part of the project, 90% of Beowulf related problems identified by QA where from Beowulf related additions to Grendel. Written with no thought to extensibility or maintainability anyone was going to have a hard time working with Grendel. Worse Grendel had no Unit Tests. Only some of the members of the team used Unit Tests and David was not one of them.

With pressure to complete the features that he had been explicitly assigned to, Ethan started  to give less help and time to Adam. Adam started to fall behind again. David started to question Adam lack of progress. Adam exploded claiming it was unfair that he was singled out. He started attacking Ethan claiming that Ethan's Project Icarus also overran its budget. He did this in Ethan's hearing and in the hearing of the rest of the team.

Ethan stopped helping Adam. He wrapped up the Beowulf features he was assigned to and they passed QA. Beowulf continued to ping pong between QA and Adams desk.

If you were interested in honesty there was plenty of blame to go around. However people interested in assigning blame are rarely interested in being honest. Adam was blamed for the overrun.

Adam was not a new employee, his strengths and weaknesses were well known. Project Beowulf was an order of magnitude larger than anything he had been asked to do before.

Shouldn't responsibility given to :-

• Carla and David for assigning a weak programmer to a task that was obviously beyond his abilities.
  
• David for the poor design of Grendel.
  
• Carla for demanding speed of completion of Grendel above all else.
  
• Carla and David for continually pulling Adam on and off the project.
  
• Ethan for not giving the help Adam needed.
  
• Adam for attacking a team member that was trying to help him.

This team had died and no one had noticed. Somewhere along the line they had become only a group of people who worked together.

I was Ethan in this scenario and I regret getting offended and pulling back when Adam verbally abused me. It wasn't his fault. The team was playing a game of hot potato and everybody knows that when you get the hot potato (blame) you pass it on as quickly as you can.

Giving Feedback (Part 1) - Why Getting Feedback Right Matters More Than You Think

Table of Contents

• Part 1 - this post
• Why Getting Feedback Right Matters More Than You Think
• Part 2
• Feedback on People Skills

• Part 3
• Taking Your Time

 

hat Good Feedback Looks Like

Effective feedback should be:

• Frequent and Timely
• Balanced—containing both affirming and adjusting feedback
• Specific—focused on behaviours that should be continued or changed

Is this what usually happens in the average work place?

No. Not even close.

More often, feedback is: 

• Delayed until the annual performance review—or not given at all
• All praise or all criticism, rarely a useful mix
• Vague and indirect
• Delivered in frustration or anger, which obscures the message
• Lacking any actionable advice on what to change or how to improve

Emotion First, Content Later

Anger especially gets in the way of effective feedback. My father used to say, "Never show anger unless you're no longer angry." And he was right. It's hard to both strike a serious tone and project the appropriate emotional weight unless you are in complete control.

People respond to the emotion in your message first. Only after they’ve processed that emotional tone can they absorb the content. So, if the emotion is hostility or disdain, defences are engaged, blame is shifted, responses are formulated, people go into "what am I going to say next" mode instead of "what did the other person just say" mode.

Douglas Stone & Sheila Heen Douglas Stone and Sheila Heen (authors of Thanks for the Feedback) offer a clear four-part structure:

• 1. Micro-Yes:
• Start with a simple, respectful prompt that invites attention:
  "Do you have a few minutes to talk about the presentation?"
• 2. Data Points:
• Share specific, observable behaviours—what you saw or heard, not vague impressions.
  Kim Scott, in Radical Candor, emphasises this too: avoid generalities and speak plainly. She calls it the “Directly Challenge” axis.  
• 3. Impact:
• Describe how the behaviour affected others or the outcome:
  "When you cut off the client mid-sentence, it made them visibly frustrated and less engaged in the rest of the call."
• 4. Question:
• End with an open question to encourage dialogue:
  "How do you think we could approach that differently next time?"

Cost of Delayed Feedback

When feedback isn't given, poor behaviour or subpar performance continues unchecked.

In a  company I am familiar with management decided to offer permanent positions to two probationary programmers even though they were unhappy with their performance. They did so because they thought that they did not have time to find and train new programmers. There was an important release coming up. There is always an important release coming up. Do I need to tell you that it did not turn out well?

Problems do not fix themselves. They compound.

Cost of Unconstructive Feedback

Worse than no feedback is feedback delivered poorly:

• Stored up and unleashed in a single dump

• Focused on personality rather than behaviour

• Public, shaming, or emotionally charged

The consequences?

• Productivity plummets

• The recipient becomes defensive and dismissive

• Hostility builds

• People disengage and look for escape routes

I’ve seen it firsthand.

Some reactions I’ve witnessed to toxic feedback environments:

• Taking recruiter calls during work hours

• Mental health breakdowns

• No-shows without explanation

• Passive-aggressive sabotage—hidden insults in code

• Starting side hustles on company time

In one case, things got so bad that the project manager told certain developers to stay home so they wouldn’t “contaminate” a new hire.

 

Summary: What to Remember 

If you take away one idea, let it be this:

Give feedback early. Be specific. Be respectful. Support change.

Don’t wait. Don’t belittle. Don’t unload six months of grievances in one sitting.

When feedback is botched, people panic. They spiral. They shut down—or they retaliate. Some maliciously comply,  working to rule.

If feedback and coaching don’t lead to change—and the behaviour clearly crosses the line—you must act. Letting problems fester only allows them to disrupt the team.

Once a working relationship breaks down, recovery becomes harder. Mediation turns into damage control. Trust erodes. Morale drops. Everyone pays.

Update:

Added more on over-utilisation and overall communication in the middle section. There was so much new material that I split it off to a new post. Then added another.

Also I have written more on an example of how not to respond to feedback.

Related Posts

• The Most Team Damaging Response Feedback I Have Ever Observed
• Have the Courage to Speak
• Sympathy Considered- Harmful 
• Giving Feedback (Part 2) - Feedback on People Skills
• Giving Feedback (Part 3) - Taking Your Time

Other Resources

Thanks for the Feedback: The Science and Art of Receiving Feedback Well by Douglas Stone & Sheila Heen

Flips the script: it focuses on how to receive feedback, even when it’s poorly delivered, unfair, or unwanted. Essential reading for both givers and receivers.

Read the book.

WSheila Heen TED Talk.

 

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Malone Scott

Challenge directly while caring personally. For those who want to foster open, honest, and respectful feedback cultures.

Read the book.

Watch the Video.

Sashimi

n Agile Project Management with Scrum, there’s a concept that really struck a chord with me: Sashimi. The idea is simple but powerful—software functionality should be delivered as thin, complete slices of value, each one fully implemented end to end.

Each sashimi slice includes:

• Working code

• Automated tests

• Updated documentation

• Data migration scripts (if needed)

• Deployment mechanism

In Agile terms, it’s done, done, done. You don’t move on until everything is complete. Not just coded—but deployable.

In the Bad Old Days

I would focus on getting the mechanics of a feature working and leave the polish—cosmetic issues, documentation, deployment steps—for later. I’d cluster features together under the logic of “efficiency,” but the result was a mounting list of lower-priority tasks that never quite got done.

Add to that the reality of interruption: just when I’d be mid-way through, I’d get pulled off to deal with a high-priority task. Then another. The result? A backlog of half-finished work that became unmanageable.

The Turning Point

To manage the chaos, I started:

• Breaking tasks into smaller pieces

• Reducing dependencies between new and old code so I could swap components more easily

Then I encountered Lean Software Development and its analogy of partially finished work as inventory—an invisible cost that clogs the system.

This clicked.

I began:

• Reducing the number of open tasks

• Limiting Work in Progress (WIP), a principle central to Kanban

• Reducing task size even further to make context switching less costly and progress more visible

Then I found Ward’s Wiki and the Extreme Programming (XP) community. There, I redefined my concept of “Done”.
Done didn’t mean “working on my machine.” It meant everything needed to ship to a user.

Evolution Through Experience

This shift didn’t happen overnight. It was shaped by:

• Hard-won experience

• Too many half-finished features

• Too many firefights interrupting other firefights

• Exposure to ideas that articulated the problems I had already felt

Why Sashimi Matters

The concept of sashimi sped up changes that were already taking place in my behaviour and made me more self-aware of the process I was undertaking.

Update:

Part of my evolving understanding of “done” now includes  

An automated build environment that runs tests as part of the process.

It's not just a nice-to-have—it's become essential.

Why? Because I’ve seen firsthand how subtle build inconsistencies can derail progress.

"It Worked on My Machine..."

There’s nothing quite as frustrating as having an application that:

• Works perfectly on one developer’s machine

• But fails when built or run elsewhere—on another machine, in CI, or in production

This doesn’t happen often; it is fairly rare. But it’s happened enough times that I no longer trust any manual process to be repeatable or reliable.

Random Quotes

have this habit of jotting down quotes that strike my fancy in my teams wiki. No-one else seems to pay much attention to them however I find it useful to re-read them every now and again.

Quotes and Concepts

• 25-to-1 productivity ratio: the observation that there is a 25-to-1 productivity ratio between the best and worst developers. Some sources insist it is 64 to 1 or higher. Fred Brooks?
• 6 degrees of Separation
  the idea that everyone on earth is connected to everyone else by a few intermediary relationships from an experiment by psychologist Stanley Milgram in the late 1960's involving a chain letter passed from Omaha, Nebraska to Boston, Massachusetts
• Chasm between Early Adopters and the Early Majority
  Geoffrey Moore Crossing the Chasm
• Code Smell
  a hint that something has gone wrong somewhere in your code More
• Conway's Law: - commonly stated as ``If you have four groups working on a compiler, you'll get a 4-pass compiler''. The original statement was more general: ``Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.'' We might put it more succinctly as ``The means determine the ends'', or even ``Process becomes product''. More
• Cost of Variety - Industrial cost goes down by about 15% to 25% per unit every time volume doubles, but goes up by 20% to 35% when variety doubles.
  George Stalk
• Empirical vs. defined processes
  Consider making cookies. You have a recipe, and you follow it. If you make another batch, with the same ingredients, in the same proportion, in the same oven, you expect to get the same result. This is an example of a defined process.
  Consider instead the process of creating a cookie recipe. The value comes from its originality. You might try a number of variations, to get just the right result. Iteration is inherently part of the process; this is an empirical process.
  See Methods and Tools Winter 2002 page 10
• Estimates
  • estimates prepared by those who will do the work are better than estimates prepared by anyone else
    Nine Management Guidelines For Better Cost Estimating. Communications Of The ACM 35:2 (Lederer 1992)
  • the people most competent in solving the task should estimate it
    (Jørgensen 1991)
  • Studies have shown that we are best at estimating when comparing things that fall within one order of magnitude
    • Improving Subjective Estimates Using Paired Comparisons. IEEE Software, 18:1 (Miranda 2001)
    • Multi-criteria Decision Making: The Analytic Hierarchy Process (Saaty 1996)
  • There is evidence that an estimate based on a developer's intuition is more accurate than other, more analytical approaches.
    Empirically Guided Software Effort Estimation. IEEE Software 17:6 (Johnson et al. 2000)
  • Popular method of agile estimating is by playing planning poker Planning Poker (Grenning 2002)
  • averaging individual estimates leads to better results (Höst and Wohlin 1998)
  • group discussions of estimates leads to better results
    A Review of Studies on Expert Estimation of Software Development Effort (Jørgensen and Moløkken 2002)
  • we are better at estimating “this is like that” than we are at estimating the absolute size of things
    (Lederer 1998; Vicinanza 1991)
• Form follows function - Louis Sullivan
• Form follows failure: "the form of created objects is always subject to change in response to their real or perceived shortcomings, their failures to function properly" Henry Petroski - The Evolution of Useful Things
• Freezing Design As soon as one freezes a design, it becomes obsolete
  Fred Brooks
• Fundamental Attribution Error
  human beings invariably make the mistake of overestimation the importance of fundamental character traits and underestimating the importance of situation and context.
• Interruptions
  managers are able to work an average of only five minutes between interruptions
  Time Power (Hobbs 1987)
• Parkinson's Law
  Work expands so as to fill the time available for its completion (1957)
• Planning
  • Planning is everything. Plans are nothing.
    Dwight D. Eisenhower
  • No plan survives contact with the enemy.
    Field Marshal Helmuth Graf von Moltke
  • A good plan violently executed now is better than a perfect plan executed next week.
  • If you tell people where to go, but not how to get there, you’ll be amazed at the results.
    General George S. Patton
• Queuing Theory
  • Little's Law
    states that in a stable system, the average amount of time it takes something to get through a process is equal to the number of things in the process divided by their average completion rate
• Reaction to a new methodology
  three-step sequence of reactions that meets the introduction of a new methodological principle: (1) “it’s trivial”; (2) “it cannot work”; (3) “that’s how I did it all along anyway”. The order may vary from Object-Oriented Software Construction by Bertrand Meyer
• Rule of 150
  150 is the maximum number of individual with whom human beings can have a genuinely social relationship. Groups work together more effectively when they are kept under the 150 member limit. From the theories of anthropologist Robin Dunbar
• SNAFU Principle: ``True communication is possible only between equals, because inferiors are more consistently rewarded for telling their superiors pleasant lies than for telling the truth.'' More
• Transactive Memory
  Close knit groups develop joint memory where each member is responsible for remembering a different portion of the joint memory - Daniel Wegner
• Triumph of Truth A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.
  Max Plank
• User Stories
• Aspects
• alliteration - Card, Conversation, and Confirmation - by Ron Jeffries
• Attributes
• acronym INVEST -Independent, Negotiable, Valuable to users or customers, Estimatable, Small, Testable - by Bill Wake (Extreme Programming Explored)
• Zero One Infinity
  Beware of arbitrary constants or limitations. The maximum size of a collection should be either Zero, One or Infinity - Professor van der Poel