Talk starts at
Very often the best way to solve problems in software is to not solve them.
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.
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.
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?
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.
One day worth of work took 60 to 70 percent of the previous year’s
18:57 And we iterated over this for less than 2 weeks.
[…] More than 99% of the invoices were being processed. And then we
Let a human do this. I have already automated away 99% of your work.
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.
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?
26:11 The question with green field is: How do I get
enough information, in order to actually be able to do things like
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.
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.
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.