Stop Over-Engineering
by Greg Young (47min)
Notes
Talk starts at 1:40.
Very often the best way to solve problems in software is to not solve them.
— Greg
03:47
04:25 Deliver value not frameworks.
09:45 When we’re in university, we are taught to think about the worst case
for things.
12:12 Business people don’t look at risk this way.
You can’t possibly enumerate all the things, that can go wrong. And this is why business people are responsive to risk not preventative.
— Greg
13:21
14:04 When you are dealing with brown field software, you have a huge
advantage: you have data. You already have users using your software.
17:17 Instead of having the domain experts explain to us how this invoicing
system needs to work, I asked them a different question:
What is my single happy path? And how do I know I’m still on my happy path?
— Greg
17:43
18:00 Then we implemented the one happy path and we tried running all of last
year’s data through it. 60% to 70% of all the invoices went down the happy path.
18:18 One day worth of work took 60 to 70 percent of the previous year’s
work.
18:57 And we iterated over this for less than 2 weeks. […] More than 99% of
the invoices were being processed. And then we stopped.
Let a human do this. I have already automated away 99% of your work.
— Greg
19:45
20:11 We can use humans as services.
20:52 That last one percent, that contains 80% of the complicated logic — just
don’t do it.
If you want a feature put into the software, you need to give me a cost-benefit analysis.
— Greg
22:14
20:20 What you need to tell me is:
- How often is this failure occurring in production?
- What is the cost per failure?
- And how much do you want me to invest?
24:50 Green field systems are really hard to not over-engineer, because you
don’t have data.
How many of you have worked on a green field project and added features, that nobody ever used?
— Gred
25:13
26:11 The question with green field is: How do I get enough information, in
order to actually be able to do things like cost-benefit analysis?
27:05 Greg’s method paraphrased:
- build the software in 20% of the planned time
- put it in production
- make people use it
- only allow bug reports and no feature requests
- people using the software can prioritise the bugs
It’s about making agreements with people, building trust, getting real information to make data-driven decisions from production. This is what agile really is.
— Greg
29:04
29:40 An analysis is not everything that can go wrong. Instead talk about:
how do I know I’m still right?
At the end of the day, the whole reason your business has a computer system, is to make humans more efficient.
— Greg
32:40
37:50 Every developer needs to go hire a developer to build something for
them. Until you’ve done that, you do not understand the economics of software
development.
39:17 I used to have another interview question I asked people: I’ve got a
file and it’s got some CSV data in it and what I want to do is get out the fifth
column in the CSV and come up with an average of the numbers. How do we do this?
40:33 The right answer in most cases of this kind of problem is: use Excel or
write a little bash script for it.