- Such a good talk
- Don’t build frameworks or other generalized solutions
- Don’t take a specific business problem and then exaggerate it into a more general problem that’s more fun to code
- You do not need to solve every problem by writing software
- If you do a cost-benefit analysis, you’ll see that the majority of the work you’re doing to automate business processes using software is losing the business money and not worth doing
- Your software is one piece of the puzzle for how a business solves its problem and succeeds
- It’s often cheaper for the business to not use software to solve a problem and instead to leave it to other types of business processes to manage those risks
- Software isn’t the right way to solve every problem
- Don’t overinvest time trying to prevent risks and bugs; instead, respond to risks and bugs when they actually occur
- Business people are responsive to risk, not preventative
- Build the happy path quickly and ship it
- Get data about actual usage
- Instead of trying to enumerate all the things that could possibly go wrong and waste time building software to mitigate those potential failure cases (which may never occur), focus on confirming you are still on the happy path, and if not, raise an exception that says a human needs to intervene
- The point of a business automating things with software is to make the human work more efficient
- If you’ve automated 90% of the work, you’re doing great
- Hand the humans the 1% of really complicated edge cases (e.g. by raising exceptions)
- Those complicated edge cases may never even happen and take a ton of time to implement handling for; just skip that stuff because of the cost-benefit analysis
- Cost benefit analysis = frequency of a failure * cost per failure / investment (how long would it take to break even on the developer time you invest?)
- Often, you should simply not spend the $ to automate complicated solutions
- You can treat humans as services when they’re cheaper than software :)
- You can use a human domain expert’s brain as the domain model instead of coding one :)
- Be extremely careful on greenfield projects where you have NO DATA about how the software would actually be used and what would actually be valuable; that’s where the risk of over-engineering is greatest
- Prefer underimplementing and shipping, and then treating actual blockers users experience as bugs worth solving since you have the data now that the update would have real value
- Don’t implement “features” without evidence they will be used
- Let the humans handle the edge cases
- The economics of software engineering are such that coding is EXPENSIVE; try to avoid spending any time coding something that will not save or generate more $ than it cost to create
- If not, let humans solve the business risk manually
- By default, have the software check “am I on my happy path? if yes, continue; else: human”; test whether you are still on the path you support; don’t test everything you don’t
- Do a cost-benefit analysis before writing any software
- If you don’t know how to do a CBA, stop and figure it out before continuing
- The goal? Deliver value. Your software has a purpose. Focus on the value you’re actually delivering. A cost-benefit analysis makes you focus on that value. The software is usually there to make or save money. When would you break even on the time you’re planning to spend on this software? Focus on not over-engineering.
Original video by Build Stuff:
From to! BUILD STUFF is going to celebrate summer! An amazing weekend on APRIL 29-30, 2017 – MALLORCA, SPAIN will take you out of the office into a seaside event full of professional lectures, technical sessions, beach games, umbrella drinks, and wonderful sunset.
Gregory Young
AUTHOR OF CQRS
Gregory Young coined the term “CQRS” (Command Query Responsibility Segregation) and it was instantly picked up by the community who have elaborated upon it ever since. Greg is an independent consultant and serial entrepreneur. He has 15+ years of varied experience in computer science from embedded operating systems to business systems and he brings a pragmatic and often times unusual viewpoint to discussions. He’s a frequent contributor to InfoQ, speaker/trainer at Skills Matter and also a well-known speaker at international conferences. Greg also writes about CQRS, DDD and other hot topics on codebetter.com.