Be Fast, Be Safe, Be Ready: Technical Advice to the People who Code for Building Agile Startups

You are a startup. Your time is precious. You don't have time to lose for delivering waste. So start with what you should have done before. Be pragmatic, be wise. This is your profession, take it serious.

Transcript

1. technical advice to the people who code for building agile startups be fast, BE SAFE, BE READY co-founder, craftbase lemİ ORHAN ERGİN
2. speakerdeck.com/lemiorhan @lemiorhan LEMi ORHAN ERGiN agile software craftsman co-founder @ Craftbase ex Sony, eBay, acm, iyzico founder of Turkish Software Craftsmanship Community
3. craftbase.io scotty Craftbase
4. in the startup world, you have to be fast Not only being first on the market is important, but also responding to customers by adding new features and eliminating bugs fast keep customer satisfaction high.
5. but… so!ware development is darn hard & complex We cannot get rid of complexity. We have to live with it. The need for speed creates an unstable, unsustainable environment, makes us stressed, less focused and less productive. It just don’t work.
6. the things you build and the things you change should work The rule is simple. It should work as expected. Bugs, errors and defects have direct negative impact on user experience and customer satisfaction.
7. you slow down due to poorly wri"en code And you start an endless “Do-Panic-Redo” loop till your product dies
8. total re-write is a solution only if you have scalability needs You have a very limited time and a few resources to implement what you have in you mind. Crappy code is your enemy. It creates technical debt and waste all around. Debts never let you continue without paying your bills.
10. having a good idea is a thing but execution is everything
11. CORE TECHNICAL PRINCIPLES & PRACTICES FOR SOFTWARE DEVELOPERS CARING THEIR STARTUPS
12. never be a… technology masturbator theoretical physicist! over-over-confident bad computer science background fanatic, technology obsessed lonely cowboy egoist negative-thinker be a doer, be pragmatic, 
 get the things done
13. Know your domain We need more domain experts 
 then framework experts in sector. Only the ones who knows the domain well can create solutions that really solve a problem.
14. Build and document system design of your product If you cannot see the big picture, you cannot manage, extend, improve and execute.
15. Build a CI/CD pipeline
 from the first day Every step you make should be validated and tested, and the pipeline should make it deployable to production
16. Start with a mono-repo Refactoring is the most common activity you do for an immature in-progress product. So do not drawn into change sets among multi repos. Start with one, split if required in the future.
17. Commit early, commit often, perfect later, publish once Commit early and often without thinking about the quality of commit messages. After you think your commit is ready to go, make it perfect by doing a code review by yourself and by writing a well- crafted commit message. Publishing is just a simple last step to share your change set with others.
18. Use trunk based development and feature flags to integrate early and often Inventory is waste. Every single minute you keep your commits waiting to be deployed to production is waste. Never allow inventory. Integrate and deploy early and often.
19. Deploy to production 
 early and often, even start from the first sprint Integration is always expensive after development starts. So focus on integration tasks first. Deploy at least one line of code to production even at the very first sprint.
20. Do not write tests to pass,
 write production code to make tests pass We simply call it Test Driven Development. TDD makes you slow down as much as you have to.
21. Your time is precious, 
 write tests at any level Validate functionality with functional & acceptance tests, check integrations via integration tests, keep your design safe via unit tests, etc. You have to write tests at any level, because your time is precious.
22. Any decisions taken before it is really required is wrong Only plan and implement the things you have details for. Do not try to predict the future and what is going to come.
23. Start with monoliths If you have no experience with building microservices at production, it could be a nightmare if you jump into it. Microservices requires to have devops culture, agile mindset and a new paradigm for software development. So be pragmatic.
24. Focus on modularity If you cannot develop well-crafted monoliths, how can you be sure you can build well- crafted microservices? Make your architecture clean and modular by following related design patterns and principles. Make your monolith well-crafted first. Then if you need to scale, split it to microservices.
25. Build your architecture to eliminate dependencies At startups, change is the only certainty. Build your architecture to eliminate dependencies and wait-times by orchestrating services in the middle of dependency graph. That allows us using stubs during development till real integration is established.
26. Program in pairs and mobs Pair programming is not a "go faster" strategy, it is a "waste less" strategy (which often results in going faster) - Kent Beck
27. I’ve never seen 
 any success
 without hard work, 
 dedication for quality 
 and failure.
28. I’ve never seen 
 any success
 without hard work, 
 dedication for quality 
 and failure. @lemiorhan LEMi ORHAN ERGiN