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:

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:

  1. build the software in 20% of the planned time
  2. put it in production
  3. make people use it
  4. only allow bug reports and no feature requests
  5. 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.

a favourite talk shared by Max