Built it, but nobody came: avoiding over-engineering
0 likes882 views
The document discusses the concept of over-engineering, defining it as unnecessary complexity in product design which stems from human nature and miscommunication. It includes cautionary tales illustrating the pitfalls of over-engineering and under-engineering, emphasizing the importance of building minimum viable products for effective iteration. The presentation highlights the need for balance in development, urging teams to focus on essential features and to avoid unnecessary changes that do not impact the final product.
Built it, but nobody came: avoiding over-engineering
- 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.