FSTO2015 - Adventures in Product Development

As developers we face different challenges in building products for clients as compared to traditional websites. Use cases typically expand from the single to double or triple digits, code has to be scalable to account for potentially colossal growth in both user base and requirements, and feature creep becomes further reaching.

User feedback becomes an even more crucial component of the development process and leniency in code quality can mean the difference between finalizing a new feature in three days and seven. When additions can impact every aspect of your project, and each day without a launched product costs the client (and your team) users, time, and money, initial detailed planning becomes immensely important.

We'll discuss the technology our team uses, the challenges we didn't expect, the things we didn't think of, the things that worked, and the things that didn't.

Transcript

1. Adventures in Product Development @kristinabalaam http://res.im/blog/adventures-in-product-development/
2. Age 10: Neopets + Video games > Web Development > Scripting High School: Comp Sci classes in Visual Basic McGill University, computer science - “concentration” in video game development Fun fact: a second year project required building an ecommerce site with C...because, obviously, C is the future of web development. Research project with Ubisoft Montreal Goodbye Ubisoft & Montreal, Hello London, Ontario ResIM (http://res.im)
3. What do I do? http://southparkstudios.mtvnimages.com/
4. “Lead Developer - Custom Web Applications” Our team: Back-end developers + front-end developer + designer + QA + PM I meet with clients, manage resources, design the best way to implement features for a project, write sprints & user stories, work with the PM to set timelines and client expectations. • Enterprise applications (tracking system for installers, resource management for health units) • Social Networks (fhmatch.com) • Dynamic application systems for universities & colleges (financial aid calculations)
5. Product?
6. Product? An application; software that you interact with at a more complex level VS
7. Our Typical Product Project Setup Agile Development: functionality sprints LNMP Linux, Nginx, MySQL, PHP Why nginx over apache? tldr: algorithm designed for Nginx allows it to scale further with fewer resources; maintains memory and CPU usage consistency better.
8. CHALLENGES
9. CHALLENGE: Client thinks their idea is GENIUS. Sometimes it is. Sometimes it isn’t. Sometimes it needs direction. Sometimes it was already purchased by a multi-million dollar corporation and they didn’t actually do any research before approaching you... TREAD CAREFULLY.
10. CHALLENGE: Maybe don’t pick a framework no one has ever used to tackle the largest project you’ve ever built. The problem with resource turnover. Laravel is great, but no one had actually worked with it - with the exception of the initial lead developer who left before development started. Don’t use your project as a sandbox for learning the framework. Schedule a bit of time into the production schedule to allow for learning the framework on a test project. Side note: Laravel docs writers - if I ever meet you, I am buying you beer.
11. CHALLENGE: Client has no clue what they want. MANY ideas. No direction. No foundation. Nothing. Image from www.dilbert.com
12. CHALLENGE: One thing often breaks (many) other things PRODUCT/APPLICATION “FLOW” TENDS TO HAVE MULTIPLE PATHS VS. A SINGLE PATH OF FUNCTIONALITY. ex. A single project can have a booking manager, instant messaging, profile management, content management, social media interaction. vs A checkout process for a website. An administrative editor for content to display on a promotional website. DIFFERENT CHALLENGES ¯\_(ツ)_/¯
13. CHALLENGE: Even a single feature change can be disastrous Your code should be built in such a way that you can add or augment features (relatively) easily...but foreseeing the need to completely change the functionality of a major feature can be tricky. Image from www.dilbert.com
14. WHERE WE SUCCEEDED
15. Code Quality & Technical Debt • Code consistency • COMMENTING • Helpful Git commit messages - “adslfjka;lfdkj” commits don’t make friends • Communication <3 http://xkcd.com/292/
16. Give a care about code quality. Trust. 1. Update obsolete comments. 2. Don’t be lazy. 3. Be nice to your future self - approach the code as though you’ll need to add some kind of functionality within the next two months. 4. Agree on structure and formatting with your team. 5. Communicate with other team members so that you don’t mess up their work. 6. Mentor newer devs, especially on large projects. More info: https://github.com/kristinaelise/FSTO-Technical-Debt
17. Give a care about code quality. Trust. With large-scale projects, and with multiple team members, you’re going to be jumping around a lot. From feature to feature, to bug fix to feature -- everywhere. Code quality cuts down on: • WTF moments • BUGS • Time required to augment an existing feature when necessary More info: https://github.com/kristinaelise/FSTO-Technical-Debt
18. Managing Resources While teams likely (and should) prioritize any bug fixes, feature requests will need to fit into an often hectic production schedule amongst other -- possibly older -- projects. This poses an interesting challenge for both the client and development team.
19. Managing Resources We maintain resources in teams specific to different development types. Our “product/application development” team, for example, works specifically on those projects considered custom applications. While resources from within this team may be shared across the company when necessary, a dedicated “product team” ensures that future adjustments can be implemented without too much delay.
20. Managing Resources What this meant? • Depending on the issue, we usually had a same-day turnaround time for bug fixes -- often within a couple of hours of receiving the error • Features were implemented much much faster • The team involved was familiar with the project
21. Organize your tasks. Communicate with your team. Making sure your team knows which tasks are completed, whose responsibility it is to actually complete them, and what those tasks entail is crucial (especially for large projects). Property of HBO’s Silicon Valley • Trello • Kanban boards • Github Issues + labels Having the ability to reference past discussions between team members and brainstorming sessions was invaluable. • Slack • Github Issues + comments • Google Docs
22. WHAT WE LEARNED
23. A foundation is crucial. You need to set project parameters and expectations early. Especially in the world of startups, there are a LOT of ideas. Many dreams. Much frustration. It’s easy to lose focus. Image from www.dilbert.com
24. Chart a Path. - as soon as we delve into the world of product development, our path becomes much more tree-like. - tasks may be well defined but a number of associated tasks must also be considered. Example: Allow User A to book an appointment with User B. How does User A find User B? Are both parties required to accept the booking request? Can User B renegotiate the requested date and time? What happens if the booking isn’t accepted within a particular timeframe? How do we notify both users of a potential appointment?
25. Chart a Path. Our task grows from building a single item of functionality to several associated items. We have to plan for all of them, along with any other associated features that relate to those associated features. As such, the feature list grows from a single path of functionality, to a tree of branching items all somewhat interrelated. Planning these paths in advance is crucial to the success of the project.
26. Chart a Path. When dealing with features that are heavily dependent on other aspects of the application, scope creep or functionality changes can have an even greater impact on timeline and code quality than with most projects. While an ideal world would afford developers and designers the opportunity to refactor and rewrite modified functionality, this is rarely the case. With many adjustments, a feature’s code base can become muddled, even hacked when too many changes are requested without ample timeline adjustments. The best way to avoid this is to be pre-emptive with the planning process. By charting out each of the possible branches a feature may require, how that feature will function, and discussing any potentially associated features, we can hope to mitigate the effects of future modifications to the feature list.
27. Chart a Path. What did we do? • Mini stand-ups with specific sub-teams : backend devs, front-end + lead, etc. • Detailed client-developer meetings -- mapping out exactly how certain features would work • Detailed sprint documents But at the early stages, we still needed more planning.
28. Document ALL THE THINGS • Scope creep. aka: You’ll have a legitimate reason to say no to certain features. • Your client won’t accuse you of trying to rob them of “crucial” functionality. • One new unplanned feature can spawn days and days of work You’re less likely to lose your mind. hyperboleandahalf.blogspot.com/.../this-is-why-ill-never-be-adult.html
29. Document ALL THE THINGS One HUGE project was completed over the course of approximately 10 months. There was resource turnover. You never ever want to rely on the client to tell you what was promised and what wasn’t. Documentation => security -- especially when passing information to new team members.
30. Document ALL THE THINGS • Every meeting should have meeting “minutes” • Clients should sign off on any agreed upon changes...just in case Image from www.dilbert.com
31. Testing is everything. A “branching” path of functionality necessarily breeds a “branching” path for testing. Testing each individual feature requires testing all associated items of functionality. Unit testing is an absolute necessity - particularly if no designated quality assurance (QA) team exists. Automated testing has been shown to have a significant positive impact on both code quality and project predictability. The more functionality covered by automated tests, the better the resulting quality of the project. (http://zeroturnaround.com/rebellabs/developer-productivity-report-2013- how-engineering-tools-practices-impact-software-quality-delivery/5/)
32. Testing is Everything How do you handle this? Your bugs move from the relatively benign “this looks broken” or “this one thing didn’t work” to: “this one thing broke, which prevented me from accessing this other functionality and not having set this one variable broke all the things.” Finished a feature? Test it. Then test it again. Then have a non-developer test it again. Within a robust, feature-heavy project and without rigorous testing at every stage of production, bugs and oversights necessarily arise. Automated testing, and a rigorous feature-based testing schedule prove invaluable.
33. QA is now your BFF “But I [developer] tested it myself! That’s good enough!” FALSE. Testing your code before submitting to QA is vitally important. (Just ask the Professional Coder’s bible: Clean Coder by “Uncle Bob Martin”)
34. QA is now your BFF HOWEVER, there’s a very good chance you’ll miss things. You (likely) aren’t a robot/cyborg. It’s easy to bypass a particular usability path that a computer illiterate user may take vs. what you’re used to following while testing as you code. Have an outside resource for testing features. Property of HBO’s Silicon Valley...and the internet
35. Your client thinks they’re your only client. This seems to be the case with most clients, but especially start-ups. Remember: • Their entire business relies on this single product • This isn’t a promotional asset; this isn’t an enterprise solution: their business can fail if this product fails But no pressure.
36. Your client thinks they’re your only client. Expect 1 am phone calls and text messages. Expect the client to possibly find you on social media and to find your personal cell phone number. Expect Power Point presentations delivered by email at 11:30 pm on a Saturday containing pseudo-comps of what updates the client would like to make. Patience. Reassurance. Communication. Enthusiasm.
37. Communicate with your client Consolidate feedback. Let the client know that they’re being heard. The client may go overboard with feedback...find a solution that manages that. Emails Awful. Awful. Google Docs Better, but not ideal. Github Issues GitHub does not provide issues-only access permissions (without creating a separate private repo). Client has access to the repo, can see internal issues and comments you may not want to share...DANGER ZONE. BugHerd So far, much better. Why we chose Bugherd: In-page feedback, Visual bug pins, Automatic screenshots, Visual Task Board, Version Control Sync, Simple Guest Access,CSV Exports
38. Just because they want to own a web product, doesn’t mean they know anything about the web. It’s easy to forget that clients often don’t know much about the internet. The IT Crowd - from giphy.com
39. Refactor when you can, wherever you can Again, unless you’re a cyborg, you’re going to occasionally write some not-so-great code. When you’re already in a function updating or bug-fixing a feature, take a look at whether you can (relatively) quickly refactor any part of it to either function more efficiently, or better follow coding standards. The CW’s Chuck
40. THANK YOU !