Designing and building something that people need is completely different from implementing what they asked for. Engineers don't like to say no; helping is empowering and pride makes it difficult to back down. Product owners don't always have the context to understand how hard it is to implement a feature and a throwaway request can add weeks to a project. We're all limited by our perspective, so the trick is to recognize what should be built practically. The goal shouldn’t be to say no, it should be to empower. Learn from our successes and mistakes! We'll discuss ways to focus feature development, manage expectations, delivering value without compromising effectiveness, and real-world examples of technically successful but over-engineered projects.

1. Built it, but nobody came:
Avoiding over-engineering
Jon Peck @fluxsauce | #SANDCamp 2016.02.26

2. Jon Peck
Senior Engineer, Four Kitchens
twitter.com/fluxsauce
github.com/fluxsauce
linkedin.com/in/jonpeck

3. What’s over-engineering?
... the designing of a product to be more robust or complicated than is
necessary for its application, either to ensure sufficient factor of safety,
sufficient functionality, or because of design errors. (Wikipedia)
Making something that isn’t used

4. Cautionary Tale
“Creative Works”
Old system had a librarian who
managed taxonomy of movies,
albums.
The librarian left, so editors reverted
to flat tags.
PO for new site wanted order.
Migrated content into clean
hierarchy, but...
PO left and the replacement didn’t
share vision. Site launched.
Today? Flat tags.

5. What causes over-engineering?
Human nature - we want to do good things
Pride - because we can
Ignorance - don’t know of a better way
Don’t care - somebody else’s problem

6. Cautionary Tale
Technical stakeholder at client
concerned about performance.
Disallowed Panels, but...
Required Panels flexibility.
Reinvented the wheel, added
dozens of hours, fragile & scary
codebase.
“Let’s reinvent Panels!”

7. Design - wireframes and mockups make it look easy
Meetings - priority miscommunication
Architecture - prescriptive requirements
Implementation - ignorance and inexperience
When does over-engineering start?

8. Success Story
Site on a tight budget has an events
calendar.
Wireframe has an RSVP.
Framework doesn’t have an off-the-
shelf events calendar.
Where will RSVPs be handled?
Off-site; just link to it.
“Event RSVP”

9. Analyze the request.
What is the goal?
Who needs this feature?
Why is this feature needed?
Is this the only way?
What data backs it up?

10. Engineer assumed support of very
old versions of IE.
Support means extra overhead.
Checked Google Analytics...
Less than 3%! HTML5 Shiv
unnecessary.
Success Story
“Minimum version of
Internet Explorer”

11. Build a Minimum Viable Product
The minimum viable product (MVP) is a product which has just enough
features to gather validated learning about the product and its continued
development. (Wikipedia)
A MVP is the basis for iteration and drives the conversation.

12. Estimation, prioritization, iteration
Define the cost of a feature.
Cost and interest drive prioritization.
Iterate beyond the MVP.

13. Cautionary Tale
Wanted optional arbitrary
placement of items in a list of
content.
Built it and the interface; worked on
it until launch.
Really only needed a sticky flag.
Editorial control over list items

14. Iteration communicates by making something tangible.
If it can’t be used, it’s not iteration.
Iteration only works if there’s something to iterate on.
Under-engineering

15. Cautionary Tale
Working on project for many
months.
Most functionality was complete;
content migrated, design was being
implemented.
“Site’s not built, we can’t review!”
Navigation wasn’t finished;
removed placeholders and finalized
menu.
“Site’s not built yet.”

16. Did I really need to do that?
Spending hours making changes that have no tangible effect on the system.
Change for the sake of change.
Artificial challenges whose solutions don’t impact the product.

17. Slippery Slope
Always apply security updates.
Always apply relevant bug fixes.
Incrementally update when
convenient and testable.
Evaluate new features, upgrade if
you need them.
Version updates

18. Cautionary Tale
Site optimization.
ESLint produced list of all problems,
including errors, warnings, and
stylistic problems.
What should have gotten fixed —
syntax errors and warnings.
What happened instead — entire
rewrite of all JavaScript.
ESLint JavaScript errors

19. Slippery Slope
for vs foreach, echo vs print,
. vs , …
No practical difference in most use
cases.
Usually makes code harder to
maintain.
Focus on big picture first — slow
queries, caching, errors...
Micro optimizations

20. Do you have a
story to tell?
Audience participation.

21. Avoiding over-
engineering is not
an excuse to say
no.

22. Thank you.
twitter.com/fluxsauce
twitter.com/fourkitchens