CTO assume way too much about what CxO actually know about software development. Yet, CxO who are not CTO have great influence over the success of the CTO. This presentation identifies a handful of core underpinnings of software development that are poorly understood by CxO. The job of the CTO, in part, is to educate CxO about these misunderstood factors that lead to successful software delivery.
3. A source of conflict
You can’t go to school to learn this stuff,
Training is on-the-job
You know a lot about making software,
And you assume other executives do, too
Who might these people be?
CFO (you knew that)
CEO and COO, too
CIO – that may surprise some of you
C-Peers are operationally focused
“The primary difference between
operations and innovation is
uncertainty. It eludes planning,
prediction and containment.”
But they don’t...
They really, really don’t
CTO Summit 2014
5. There’s no
place for hope
Common misunderstandings
(and what you can do)
● Skill matters … Productivity varies widely
● Size matters … Big is bad
● …A business case ...
● Hard v. easy… Helping them frame it up
● Software quality … If it hasn’t yet, it won’t
● Fighting for resources… Not new toys, productivity
● Big bang … Lehman’s Laws (evolving software)
● Software management not project management
● The only metric… Working software
● Commitment v. accountability … Triangle of plausible deniability
We’ll cover 3-4 of these today ...
CTO Summit 2014
6. “Most things in life, the dynamic
range is at most 2:1… In software...,
the difference between average and
best is 50:1, maybe 100:1… I’ve built
a lot of my success by finding…”
~ Steve Jobs: Lost Interview, 39:15
“...that ‘There are order-of-magnitude
differences among programmers’ has
been confirmed by many... (Curtis
1981, Mills 1983, DeMarco and Lister
1985, Curtis et al. 1986, Card 1987,
Boehm and Papaccio 1988, Valett and
McGarry 1989, Boehm et al 2000).”
~ Steve McConnell, Construx
Skill matters
Individual productivity varies widely
What they think
● Competency is
sufficient
● Lower rate saves $
● Hiring faster is
better
● Salary is all that
matters
The reality
● 50:1 productivity
● 3:1 rate
● Bad hires hurt -
NNPP
● Non-salary
factors are deal-breakers
CTO Summit 2014
What you can do
● Measure &
benchmark
● Hire fast, but no
faster
● Prune quickly
● Battle over
hygiene factors
7. Size matters
Big is bad
CTO Summit 2014
“Can’t we just hire 150 people and get it done in a year?
IBM would.” ~ An ex-CFO
The Army is focused on the squad [8-
12 man unit] as a system and as the
foundation of the decisive force.
~ Gen. Gordon R. Sullivan
Research … has revealed there is an ideal
size for a working group. This ideal size
is between eight and twelve individuals.
~ Edward T. Hall, Anthropologist
From 2003 to 2012, only 6% of federal IT projects with over $10 million of
labor cost were successful. 42% were outright failures.
~ The Standish Group
…conceptual integrity is the most important consideration in system design.
…[it] in turn dictates that the design must proceed from one mind, or from a
very small number of agreeing resonate minds.
~ Frederick P. Brooks
No. Size the work to fit the team & amp productivity.
8. … and periodically throughout
What’s a razor?
A simple rule that helps you
decide what’s “in” and what’s not.
The business case
Gut-check early & often
Before you start
● Clear objective?
● Is it financially sound?
● What if cost & time double?
● What if functionality doubles?
● Create a razor
Q. How much will it cost?
A. How much are you willing to pay?
After you start
● Defend against scope drift
● Ask to wield the razor
● Read them “the epitaph”
➢ A market center: “If we don’t do this, will the SEC prevent go-live?”
➢ A merger consolidation: “Is this more than they have today?”
[feature]
CTO Summit 2014
IRACIS – Rev., Cost, Sat.
9. CTO Summit 2014
Some things are easy, some hard; outsiders can’t
tell which is which
How hard is that?
You can do that tomorrow, right?
The consequences are often:
● Blown business commitments
● Floggings and Death marches
● Over-complicated solutions
What to do?
(Ridicule won’t work … trust me)
● Own commitments
● Is it Research, Eng., or EUC?
● Proof by end-to-end demo
● Deliver frequently
LEF intro to establish bona fides
20 years developing software products
Research programmer in biomedicine
CTO & VP at two search engine companies
Consulting for private sector firms
IT practitioner for the last 12 years
As SVP of private sector regulator
Over 8 years, rebuilt an outsourced development operation from 1-500+ staff
Worked with IT at numerous Financial Services firms
As president of a software services firm
Supporting IT at a number of agencies and firms
Collaborating with dozens of other agencies, firms and vendors
Have had chance to see a lot of projects in a lot of organizations, and I want to share some of my observations with you.
This talk is about communication, actually, about miscommunication due to fundamentally different assumptions about your world, our world
I have no special expertise to be talking about this, other than self-preservation and professional survival; I like being around highly skilled people, and these are the things that I’ve had to confront in order to make that possible
My background is a little varied, so I’ve been exposed to different views of the problem. 8 year,s, 12 years, 8 years, last few
The primary difference between operations and innovation is uncertainty. It eludes planning, prediction and containment.
http://www.1000ventures.com/business_guide/innovation_vs_operations.html
Why am I telling you about this topic…
http://www.computerworld.com/s/article/9243396/Healthcare.gov_website_ddent” process
It has it’s own acronym, the NNPP - Net Negative Producing Programmer: In a paper by Gordon Schulmeyer: The Net Negative Producing Programmer he says “In a team of ten, expect as many as three people to have a defect rate high enough to make them NNPPs.”
In an article titled “Dealing with problem programmers,” IEEE Software V15 No 2, 1998, Steve McConnell cites a few papers. A Bill Curtis study from 1981. In that study, 6 of 60 of professional programmers failed to complete a “simple debugging task.” In another paper published in 1985, Tom Demarco and Tim Lister published a study of in which 13 of 166 programmers failed to complete the task.
This has given rise to the 10% number. The reality of NNPP is well-known to programmers.
In the blog post “Origins of 10x - How valid is the research”, Steve McConnell goes pretty deep and cites a large number of studies documenting the 10-100x productivity difference between competent programmers, the earliest dating to 1968. In fact,numerous studies have documented differences of between 5:1 and 100:1 over the last 50 years.
the general finding that "There are order-of-magnitude differences among programmers" has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000).
Dunbar number
Fred P Brooks MMM, surgical team 10
http://www.ausa.org/publications/ilw/Documents/TB_The_Squad_web.pdf
The Army is focused on the squad as a system and as the foundation of the decisive force. Gen. Gordon R. Sullivan
https://signalvnoise.com/archives2/edward_hall_the_perfect_group_size_812.php
“Research with business groups, athletic teams, and even armies around the world has revealed there is an ideal size for a working group. This ideal size is between eight and twelve individuals. “
Edward Hall, Anthropologist
http://bfwa.com/2012/06/04/rise-the-mythical-man-month-frederick-p-brooks-jr-19751995/
Examples,
procurement system on BPM (demo was good; delivery was a nightmare)
programmers can read code?