As mentioned earlier, I like listening to SE Radio. Here are some insights on the usefulness of type systems, project kickoffs, the impact of what you call the faults you make, how simple systems get complex by themselves, the roles in the adoption curve, digging into software to find out the context of its creation, why abbreviations are bad names, the key role of feature teams, and seelenverwandschaft.
- 140: Newspeak, tough on modules, lax on types
- 83: Feature Driven Development, XP without Pairing and TDD
- 280: Weinberg, automated Tests are like Power tools
- 285: Dropbox, creating a simple system that gets complex from its billions of users
- 139: Linda Rising, fearless change by asking for help
- 148: Software Archeology, finding out what those people were thinking back then
- 278: Naming is difficult
- 170: Large Scale Agile requires feature teams
- 131: Observations of Adrenaline junkies and jelled teams
140: Newspeak, tough on modules, lax on types
This is an interview with Gilad Bracha who was heavily involved in developing Newspeak. He has a lot of real-world experience building things like the JVM specification and collected a lot of experience building type systems which led him to some interesting conclusions e.g. on type systems:
- Static typing is most valuable as documentation for humans and machines.
- The execution of the software is not made more reliable through static typing: A type checker can only tell you that your program is not good (in its sense of goodness), but it can not tell you that it is not bad (e.g. not crashing) either.
- Static typing enables only minor optimizations - most JVM optimization techniques were invited for Smalltalk and Self, both dynamically typed languages
- IDE support is better with static typing, however some important IDE actions like Refactoring were first invented for dynamically typed languages
- On the other hand, type systems make it hard to invent things, because it is hard to be creative and invent things that the language design did not think of
In Newspeak, type information is regarded as additional meta-information that may be used, or may be ignored by the compiler. I really like this view, since this allows you to get the benefits of static typing without being overly constrained by it. Elixir follows a similar route with typespecs.
83: Feature Driven Development, XP without Pairing and TDD
FDD is basically Jeff DeLuca’s approach to project management written down, because lots of people liked it a lot. What I liked about this episode is that Jeff made it clear in the beginning that he always works with whatever works for people and then adds things he know that works. This was my most important lesson. Apart from that FDD contains some good ideas:
- At the beginning of a new project, he does a kickoff phase of roughly 1 week per 3 month of the project with engineers, end users and stakeholders. The point is not to actually create something (they try of course), but the collaboration with actual users and knowledge transfer that ensues.
- In his opinion FDD is mostly like XP, just without Pairing and TDD
280: Weinberg, automated Tests are like Power tools
I love Gerald Weinberg and was really looking forward to this one and finding more Stones. It was worth it! His opinions from 50 years of experience are invaluable:
- Calling faults “bugs” somehow implies that they creep into programs without people looking. This is completely wrong and dangerous. Do not call faults and errors bugs.
- Automated testing is like having power tools: Used wrong, you get more scrap wood faster
- A fascinating story about personal motivation of a company that wanted to introduce code review for all employees. Most agreed, but there were 3 developers that refused to let anyone view their code. So the company allowed them to go ahead, but in case these programmers caused faults they would have to pay it from their salary.
- The first programmer agreed to do code reviews instead.
- The second programmer still refused, very soon caused a fault that cost a lot of money (more than his annual salary), so the company offered him to leave without paying for the fault
- The third programmer had his own methods to make sure that he did not cause faults and created perfectly fine code for 7-8 months. However then a little mistake wiped out an important database: He would have had to work for the rest of his life for free in order to pay for this. Instead of letting him go though, the company asked him to instead train the others to work like you.
- To the closing question of the interviewer if they have forgotten something: “Of course we have forgotten things, this is your one lesson!”
- And one closing life lesson: Commit yourself to getting feedback an using that continuously. Keep improving all your life: I have been for 70 years and I am better at what I do now, because I improved!
285: Dropbox, creating a simple system that gets complex from its billions of users
James Cowling talks in this episode about how Dropbox moved from Amazon S3 to a custom storage system, that was more tailed to its (read-heavy) use case. Interesting lessons:
- The real world has really interesting problems, that you can not use computer science against: cooling systems may spill over, trucks full of new hard disks may crash into each other and loading docks may be full and new hard disks can not be brought into the data center
- They took a very slow, incremental approach to launching their own storage system, with integrity of data as the highest goal
- Simplicity is super important when building a large system, the complexity will come just by itself.
- After a few first prototypes to see whether this actually makes sense, they knew they were going to get serious and created a launch clock, together with a contract about when the clock will get reset. After a few months of smooth progress, a fault got to the staging environment without being detected. This was not really a violation in terms of the contract, however the team voluntarily reset the launch clock, because it felt dirty not to
- They should have invested earlier in operations automation, that would have saved them a lot of time
139: Linda Rising, fearless change by asking for help
My most important insight from this episode is that the adoption curve is about roles, not about people. Nobody is open for everything, for example somebody who really likes to try out new things in her development process might be very conservative in her eating habits. This is also no scale of good or bad: Every role has its justifications. An attitude of “let’s remove those laggards” thus does not make any sense.
Another cool example of the patterns in her book Fearless Change is “Ask for help”. For example if you want to introduce something new in a process, get the process guard and ask him for help how to fit this into the existing rules, because he is the one who knows best about them.
148: Software Archeology, finding out what those people were thinking back then
Software Archeology is, just like real archeology, about finding out how something was used: what kind of team, process, IDE, code policies etc. were used to create this piece of software. You can then use this knowledge to get into those persons heads and anticipate their decisions. Observations from a long-time archeologists:
- Comments almost always obsolete. Even if they are, the most useful ones are navigational comments that link the code to other material that might reside outside the code base, for example books, config files …
- Sometimes it is easier to throw an exceptions instead of setting break points
278: Naming is difficult
In this episode there was one very good argument against abbreviations: Peter Hilton created an awful bug, because he was working a database that had a “char” field and he assumed it was “character”. However, it was “characteristic”.
170: Large Scale Agile requires feature teams
This episode supports my opinion that feature teams are the most important and most difficult part of agile software development:
- The transition to feature teams takes years, so it is best to introduce them gradually to not have pain all at once
- Frozen interfaces are a sign of component teams, since they are used to mark team boundaries. In feature teams interfaces may change inside the feature team, which may span several component boundaries
- I experienced this at work: The traveler pattern, generalist engineers that join 1 team per iteration by their own choice
131: Observations of Adrenaline junkies and jelled teams
Their book of a similar name is a collection of their 150 years of software development experience. In it the 4 authors share their observations from the industry (but not solutions, since those depend on the context). To write it, they did not follow the rather strict GOF pattern template (because they are no template zombies), instead they wrote them like essay like in Christopher Alexander’s books.
The coolest pattern in my opinion is “Seelenverwandschaft” (kinship of souls) that describes teams that create great things, without following any of the organization’s guidelines.