The Art of Destroying Software
by Greg Young (42min)
The waterfall paper is one of the biggest ironies in our industry. If you go and read the waterfall paper, it basically describes what you know as agile throughout the paper.
02:30 The “Big Ball of Mud” paper argues that the big ball of mud is
inevitable and optimal, because of the economics of software.
03:00 Instead of building one giant ball of mud, create many little ones.
Unit tests only show that the tests passed, they don’t show lack of bugs.
The definition of a refactor is: I either change my tests or my code and I only change one out of the two.
07:28 Greg’s Law: Looking at software, one can tell what tools were used to
write it, because tools affect code.
09:50 Being able to take a piece of code, delete it and rewrite it from
scratch in one or two days is extraordinary valuable.
11:50 We optimize for deletability by moving away from monoliths and optimize
13:58 Greg’s rule of thumb: The time it takes to do a full rewrite for part of
the software should not exceed one week.
14:14 Technical debt is not a concept business people understand.
15:56 Debt is not inherently a bad idea. You get something for the debt you
are taking out.
20:23 If you can rewrite a piece of code in a week, you can understand it in a
21:30 Write small, manageable programs, that coordinate to get the job done.
22:53 You know the most about your project at the end after you’ve done
everything, not at the beginning while planning.
23:08 At any point in time, I’m willing to delete my code and rewrite it from
scratch. This is the unix philosophy, this is the Erlang philosophy, this is
microservices, this is SOA, this is actors.
The problem is most people are picking up these ideas and they are never understanding the fact that the goal is to delete your code.
Alan Kay said the biggest mistake he made with object-orientation was naming it object-orientation. He should have called it message-orientation, because people think about it now as the objects, not about the messages that go between them.
30:04 The one big secret to great consulting: Never build big programs.
The difference between great code and sucky code is the size of the programs.
31:05 You will never understand a hundred thousand lines of code at the same
time. It’s impossible. You can not keep that much in your head.
Teams inherently want to build programs that are too big and too complex.
36:34 Don’t try to plan for future changes. Focus on the ability to
completely rewrite everything from scratch when that change actually occurs.
37:10 Make the decision at the last responsible moment.