Steve McConnell is CEO and Chief Software Engineer at Construx Software where he writes books and articles, teaches classes, and oversees Construx’s software engineering practices.

1. Steve McConnell
CEO and Chief Software Engineer,
Construx Software
Submitted to: Sir Ansar Mohammad
Presented by: Mohammad Rizwan
[SP16-MS-0026]

2. Who is Steve McConnell?
• Steve McConnell is CEO and
Chief Software Engineer
at Construx Software where
he writes books and articles,
teaches classes, and oversees
Construx’s software engineering
practices.

3. Who is Steve McConnell?
• Steve received a Bachelor’s
degree in philosophy (minoring in
computer science) from Whitman
College.
• Earned a Master’s degree in
software engineering from Seattle
University.

4. Who is Steve McConnell?
• Steve McConnell is CEO and Chief Software
Engineer at Construx Software
• In 1998, readers of Software
Development magazine named Steve one of the
three most influential people in the software
industry along with Bill Gates and Linus
Torvalds.
• Steve also served as Editor in Chief of IEEE
Software from 1998-2002 and is a member
of IEEE Computer Society and ACM.

5. Industry Contributions & Affiliations
• pursued a career in the desktop software
industry, working at
– Microsoft, Boeing, the Russell Investment
Group and several other Seattle area firms.
• At Microsoft, McConnell worked
on TrueType as part of Windows 3.1.
• At Boeing, he worked on a Strategic
Defense Initiative project.

6. Construx Software
(Background)
• Construx helps software development
organizations become more productive
and get to market faster with high quality,
innovative products.
• For 20 years we have been providing
insight, techniques, and recommendations
through training and consulting on
software development best practices.

7. Construx Software
• Construx cover the complete software
development life cycle, with a practical
approach that helps you meet business
goals.
• One of the coolest things we've created is
our Professional Development Ladder. We
have used this internally for several years
and are now offering it to other companies.

8. Construx Software
• 10:1 difference in productivity among
different programmers with similar levels
of experience,
• and the same 10:1 difference applies to
different teams working within the same
industries.
• Professional development bridges the gap
and helps organizations become more
productive, produce higher quality
software.

9. Sample Professional Development
Plans for developers, testers, and managers.

13. Further Reading
• You can visit the URL below to see the
other samples of professional
development ladder as a Tester or a
Project Manager.
• http://www.construx.com/Resources/Samp
le_Professional_Development_Plans/

14. Books
• Steve is the author of
1. Code Complete (1993)
2. Rapid Development (1996)
3. Software Project Survival Guide (1998)
4. Code Complete 2 (2004)
5. Professional Software Development (2004)
6. Software Estimation: Demystifying the Black
Art (2006)
• (twice won Software Development magazine's Jolt Excellence award for
outstanding software) development book of the year.

15. 1. Code Complete
(1993)
• Jolt Excellence Award -1993
• It's been superceded by CC2,
but for people who are still
working in C, Pascal, GW-
BASIC, and similar languages,
it's still relevant.
• but the focus is on
programming techniques that
can be used in all languages.
• up-front planning, applying
good design techniques to
construction, using data
effectively, reviewing for errors,
managing construction
activities, and relating personal
character to superior software.

16. 2. Rapid Development
(1996)
• Jolt Excellence Award
• Strategy and best practices for
optimizing software
development schedules.
• Rapid Development tells the
reader what is needed to move
toward the "10" side of that 10-
to-1 ratio.

17. 3. Software Project
Survival Guide (1998)
• A step-by-step guide to
running a successful software
project.
• For those who are not given
any formal or informal training
• SPSG provides an introduction
to the steps for technical and
nontechnical readers.
• The plan described in SPSG is
designed to address the most
common weaknesses that
software projects face.

18. 4. Code Complete 2
(2004)
• A practical handbook of software-
construction practices.
• Updated for web development,
object-oriented development, agile
practices, and other modern
construction issues.
• Code Complete 2 focuses on
programming principles that are
relevant to software construction.
• Areas Covered
– Laying the Foundation
– Creating High Quality Code
– Variables
– Statements
– Code Improvements
– System Considerations
– Software Craftsmanship

19. 5. Professional Software
Development (2004)
• This book is about the emerging
profession of software engineering
and professional software
practices that support economical
creation of high-quality software.
• Software development can be
predictable, controllable,
economical, and manageable.
• Software isn’t usually developed
that way, but it can be developed
that way.

20. 6. Software Estimation:
Demystifying the Black
Art (2006)
• Software estimation is not as hard
or mysterious as many people
think,
• but the knowledge of how to
create effective estimates has not
been well publicized.
• Software Estimation provides a
comprehensive set of tips and
heuristics that software
developers, technical leads, and
project managers can apply to
create more accurate estimates.
• It presents fundamental estimation
techniques and addresses specific
estimation challenges. It explains
how to avoid common pitfalls.

21. 6. Software Estimation:
Demystifying the Black
Art (2006)
• Software Estimation doesn’t avoid
hairy mathematical approaches,
but the non-mathematical reader
will find plenty of useful guidelines
without getting bogged down in
complex formulas.
Cont.

22. The Cone of Uncertainity

23. The Cone of Uncertainity
• The Cone of Uncertainty, described by
Steve McConnel,
• shows what any experienced software
professional knows. Which is at the
beginning of any project we don’t know
exactly how long a project is going to take.

24. The Cone of Uncertainity

25. The Cone of Uncertainity
• The reasons for this are many. No two ever projects have:
– The same requirements.
– The same people.
– The same business context.
– The same technology.
– The same priorities & constraints.
• Each is unique. Every line of code is hand crafted. And knowledge
work involving smart creative people doesn’t lend itself to precision
the way ditch digging does.
• Sponsors want to know exactly when the project will be done, and
how much it will cost.
• Dealing with this conundrum is almost as old as time itself. Here are
a few ways teams and companies are deal with this uncertainty.

26. Dealing with the cone
• Pad the estimate
– After feeling the sting of underestimating, one common reaction
is to double or triple the estimate the next time round. This
definitely lowers the upfront risk, but padding the numbers is
harder than it sounds.
– Give too big a number, and sponsors will not approve your
project. Give too low a number and you risk running out of
money. This gets doubly dicey when you are bidding on fixed bid
contracts where there is even more pressure to keep the
numbers down.

27. Size the project relatively
• Humans are really good at sizing things relatively. We
can’t tell you precisely how big a rock is. But we can tell
you how big it is compared to something else. We can
use this when sizing projects too.

28. Be upfront and honest
• Look. We don’t know how long this is going to take. This is our
best guess. But if you give us a couple iterations, we can build
something, measure how long that takes, and then tell give you
a much better sense of how big this thing is.

29. Fund incrementally

30. Fund incrementally
• With incremental funding you don’t ask for the
whole bag of money upfront. Only enough to
spike through enough of the work, to report back
a better number on how long it is going to take.
• It’s not foolproof. You can still run into trouble
later on.
• But by giving teams $30-50K, letting them build
something and seeing how long that takes, can
go a long ways to reducing the variance in that
upfront number.

31. Relationship Between the Cone of
Uncertainty and Commitment
• Software organizations inadvertantly sabotage
their own projects by making commitments too
early in the Cone of Uncertainty.
• If an organization commits at Initial Concept or
Product Definition time, it has a factor of 2x to 4x
error in its estimates.
• Commitments made too early in a project
undermine predictability, increase risk, increase
project inefficiencies, and impair the ability to
manage a project to a successful conclusion.

32. The Root Cause
• If you find yourself getting tripped up by the cone
of uncertainty, just remember the whole point of
software estimation is to determine whether the
project is even possible.
• Or as Steve McConnell says:
“The primary purpose of software estimation
is not to predict a project’s outcome; it is to
determine whether a project’s targets are
realistic enough to allow the project to be
controlled to meet them.”

33. Non-Work Interests
• Steve lives in Bellevue, Washington, with my
wife and children.
• Car Wax - tried different waxes on Audi A6
• Weather: can see current weather on his
website.
• Home Theater Outside work Steve’s biggest
project was building a home theater.
• Home Improvement

35. Contact
• Email: stevemcc@construx.com.
• http://www.construx.com/
• +1(425) 636-0100
+1(425) 636-0159 fax
• Construx Software
10900 NE 8th Street
Suite 1350
Bellevue, WA 98004