prescriptive. More like a bunch of guidelines & principles. • How do we put it into practice? • For many of us, we don’t care about buzzwords. • We care about getting the right things done. We care about getting things done right. • Its become the natural way in which we build software. Do what works
software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan http://agilemanifesto.org/
what is the right things to build. • Hypothesis -> Build -> Validate -> Repeat • Hypothesis - Customers at Starbucks would like to pay with Bitcoin. • Build - Draw some screenshots, low fidelity. • Validate - Survey a bunch of people at Starbucks. Valid? Invalid? • Repeat - Come up with higher fidelity screenshots… until a working MVP. • Be willing to ask questions.
• Business owner / product owner, users/customers, other developers, investors, etc… • Communication is key to helping everyone understand why and what we are building. • Agree on team norms and standardised practices • Team > Self (Team > Product)
a tendency to over-engineer things. • Future proofing, considering all the possible use cases is wasteful. • Unholy Trinity: Better vs Faster vs Cheaper • Build for right now. But also build in such a way that doesn’t make it too expensive to make changes. • Design patterns helps you design your code in such a way that is extendible without much code changes to legacy code.
We also hate repetitive tasks. • Automated testing lets us verify quickly that our code works as expected. It is also a very repetitive task. • Write Test (red) -> Write Code (green) -> Refactor -> Repeat • Tests also helps us clean up / refactor our code with more confidence. It also guards against regression bugs.
coverage desirable? • No, 100% test coverage is a vanity metric. • A undiscovered bug is a test you have not written yet. • Code review helps. Code scanners help too. • Invest time in preparing and building out your test suite. Its super helpful when you are tired or facing crunch time.
now) • Building lean means making some compromises on your grand vision until its validated. • Ask yourself, will the product suffer from the lack of this feature? Will the user experience be any less delightful? • With limited time and limited run-way (funds) to build traction on your software, you have to prioritise.
feedback • Project management tool • Version Control Software (and where to host it) • Continuous Integration (and test suite) • Code standards • Where to deploy your software to for user acceptance • Continuous Deployment
Tracker. • Use Test Driven Development (TDD) to build out the feature. • Pair Programming for shared knowledge of the code. • Driver/Navigator, Tester/Coder, Pilot/Co-Pilot • Commit and push to GitHub. Trigger CI. • Code review via Pull Requests. • Accepted PR will trigger a deployment to QA environment.
• Meetup.com, Facebook Groups, WeBuild.SG. • Meet your peers, seniors and other professionals. • Open sharing of knowledge in the Open Source communities. • Participate in Open Source projects. • Pull requests helps you get noticed and learn from your peers.
engineers, designers and makers in Singapore. Come down and have a brunch. Bring someone new, someone curious. Saturday Feb 11 @ 11:00 AM Wheeler's Yard Bike, Singapore