Archive

Posts Tagged ‘software development’

Customers, Features, Components

March 14, 2016 Leave a comment

Umm, let’s see. Customers interact with features. Features are implemented across components. Components are designed/coded/tested/integrated by developers. Well, duh!

CompsFeatures

 

 

Event Driven Behavior

February 21, 2016 2 comments

The Promotion Strategy

February 18, 2016 Leave a comment

On the left side of the following figure, we have a typical mega-project structure with a minimal Overhead-to-Production personnel ratio (O/P). If all goes well, the O/P ratio stays the same throughout the execution phase. However, if the originally planned schedule starts slipping, there’s a tendency of some orgs to unconsciously exacerbate the slippage. In order to reign in the slippage via exercising tighter control, the org “promotes” one or more senior personnel out of the realm of production and into the ranks of overhead to help things along.

moreoverhead

By executing the “promotion strategy“, the O/P ratio increases – which is never a good thing for profit margins. In addition, the remaining “unpromoted” senior + junior analysts and developers are left to pick up the work left behind by the newly minted overhead landlords.

So, if you’re in the uncomfortable position of being pressured to increase execution efficiency in order to pull in a slipping schedule, you might want to think twice about employing the “promotion strategy” to get things back on track.

The brilliant Fred Brooks famously stated something akin to “Adding people to a late project only makes it later“. In this infamous post, dimwit BD00 states that “Promoting personnel from production to overhead on a late project only makes it later“.

The Efficient, The Troubled, The Dysfunctional, The Apocalyptic

February 12, 2016 Leave a comment

The Big Ones

Damn, these are the kinds of bugs I keep finding in my code!

Huge Bug

Perhaps it’s time to find a new vocation?

Note: Thanks to @RiczWest for pointing this out to me.

Who Dun It?

July 6, 2015 2 comments

Assume that the figure below faithfully represents two platform infrastructures developed by two different teams for the same application domain. Secondly, assume that both the JAD and UAS designs provide the exact same functionality to their developer users. Thirdly, assume that the JAD design was more expensive to develop (relative depth) and is more frustrating for developers to use (relative jaggy-ness) than the UAS design.

JaggyAndDeep

Fourthly, assume that you know that an agile team created one of the platforms and a traditional team produced the other – but you don’t know which team created which platform.

WhoDunIt

Now that our four assumptions have been espoused, can you confidently state, and make a compelling case for, which team hatched the JAD monstrosity and which team produced the elegant UAS foundation? I can’t.

It’s All About That Jell

Agile, Traditional, Lean, Burndown Charts, Kanban Boards, Earned Value Management Metrics, Code Coverage, Static Code Analysis, Coaches, Consultants, Daily Standup Meetings, Weekly Sit Down Meetings, Periodic Program/Project Reviews. All the shit managers obsess over doesn’t matter. It’s all about that Jell, ’bout that jell, ’bout that jell.

Jellin

 

 

All About The Jell

%d bloggers like this: