John Coggeshall has 18 years of experience in web development and PHP. He discusses several projects that failed due to neglecting technical debt, overcomplicating projects, and ignoring expert advice. Some key lessons are to have expert skills as partners rather than employees, manage expectations, be flexible, have a development process, and keep things simple.

1. John Coggeshall

2.  18 years in web development, PHP
 Former Sr. Architect, ZendTechnologies
 Core PHP Contributor
 Startup CTO
 Business Owner

3.  This is going to be an entertaining talk about
failure
 I’m pretty good at failure
 I’ve watched a lot of people fail too
 I’ve also learned a lot in the process
 Names have been changed to protect me as
necessary

4.  ?????
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????

5. Act I

6.  New minted consultant at
ZendTechnologies
 First big project is working
on Signature Network’s
biggest client, the band U2

7.  The project was doomed
from the start
 Technical Debt isn’t like a
bank loan, it’s like the
mob.
 Bono publically
apologized for the failure
(awesome)

8.  Do not neglect
technical debt
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????

9.  Hired by another
development shop
to work on the
Amp’d Mobile
backend
 Severely over-architected
CMS
 Wouldn’t scale, all
hope is lost. “Amp'd Mobile takes the crown for money-burning
with $360 million in losses.” – Quicken

10.  Do not neglect technical
debt.
 Do not overcomplicate.
 Do not ignore the advice
you are paying for.
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????
 ?????

11.  Joe is a construction guy and he had an idea
for a great new web site that was going to
make all sorts of money
 Joe doesn’t know the first thing about
programming web sites, but what problem
could that be? He doesn’t need to know
right?
 Let’s talk a bit about Joe.

12.  It’s okay if you want to start a tech company
but don’t know how to write code
 It is not okay to do so without having a
quality partner who does
 It is not an acceptable substitution to just hire
a programmer employee and rely on them for
business decisions

13.  Do not neglect technical debt.
 Do not overcomplicate.
 Do not ignore the advice you are
paying for.
 You must have expert skills in
your tech as partners not
employees
 You get what you pay for, don’t
be cheap.
 ?????
 ?????
 ?????
 ?????
 ?????

14.  Despite what you might think from this talk, I
am actually pretty good at my job.
 Hired on as CTO to a startup called Individual
Digital
 Like many fledgling startups, we had plans to
take over the world.
 …. And we failed.

15.  We were well funded.
 We had good ideas.
 We had good market opportunities.
 We had good tech and the staff to run it.
 We had it all, but one thing

16.  We displeased our masters (investors) by
tying the success of our product to a single
thing.
 As executives / founders we allowed
ourselves to be boxed in to what amounted
to acceptance criteria
 We were succeeding in building a business,
just not the business our investors wanted.

17.  Do not neglect technical debt.
 Do not overcomplicate.
 Do not ignore the advice you are paying
for.
 You must have expert skills in your tech
as partners not employees
 You get what you pay for, don’t be
cheap.
 You must manage expectations
 You must be flexible
 ?????
 ?????
 ?????

18. Act II

19.  What follows
happens almost
every time I walk into
a project
 Many of you have
experienced this
 We can all
commiserate
together!

20.  Any project of any size needs a way of
managing the tasks to get it done
 Word docs are great for first cuts into a new
project, but break that down into discrete
tickets
 Pick a philosophy for development, I really
don’t care if it’s Agile or Waterfall – and stick
to it.

21.  Do not neglect technical debt.
 Do not overcomplicate.
 Do not ignore the advice you are paying
for.
 You must have expert skills in your tech
as partners not employees
 You get what you pay for, don’t be
cheap.
 You must manage expectations
 You must be flexible
 You must have a development process
 ?????
 ?????

22.  In life, in development, in anything. Never
forget KISS
 Keep requirements clear but simple
 Keep features lean and useful
 Keep architecture clean and expandable
 Keep process structured and habitual

23.  Do not neglect technical debt.
 Do not overcomplicate.
 Do not ignore the advice you are paying
for.
 You must have expert skills in your tech
as partners not employees
 You get what you pay for, don’t be
cheap.
 You must manage expectations
 You must be flexible
 You must have a development process
 You must keep things simple
 ?????

24. Last but not least….
Follow me on Twitter @coogle, Check out my code on Github (coogle)