I feel like most of what he talks about is common knowledge now. But then again, I stumble upon code written by experienced developers that is just like the one he started with: unclear responsibilities, poor encapsulation, etc. What is even worse is: I sometimes catch myself writing code like that :)
What we do requires continuous attention to detail. We sometimes get tired or lose focus. And that may result in poor quality code. However, that’s only one reason to end up with such code. I think the other (and more common) reason is accumulating functionality. Einar Høst’s talk about technical debt touches upon that aspect. You start with a beautiful model. But then if statements start raining on it. If we are not diligent, we end up with a mess.
I feel like most of what he talks about is common knowledge now.
You would be surprised how uncommon this knowledge is, and how many developers I introduced to domain modeling by sending them this video :)
What we do requires continuous attention to detail. We sometimes get tired or lose focus. And that may result in poor quality code.
This is definitely true. I think maintaining and adding features to existing software is a lot like gardening. There are always tiny chores to do, you need to be constantly reorganizing small parts of the garden, there are always new opportunities for small improvements, and if you neglect doing them for a while, the problems add up, and the entire thing ends up looking messy and terrible to work with.
Good talk. Watching refactoring is fun.
I feel like most of what he talks about is common knowledge now. But then again, I stumble upon code written by experienced developers that is just like the one he started with: unclear responsibilities, poor encapsulation, etc. What is even worse is: I sometimes catch myself writing code like that :)
What we do requires continuous attention to detail. We sometimes get tired or lose focus. And that may result in poor quality code. However, that’s only one reason to end up with such code. I think the other (and more common) reason is accumulating functionality. Einar Høst’s talk about technical debt touches upon that aspect. You start with a beautiful model. But then
ifstatements start raining on it. If we are not diligent, we end up with a mess.You would be surprised how uncommon this knowledge is, and how many developers I introduced to domain modeling by sending them this video :)
This is definitely true. I think maintaining and adding features to existing software is a lot like gardening. There are always tiny chores to do, you need to be constantly reorganizing small parts of the garden, there are always new opportunities for small improvements, and if you neglect doing them for a while, the problems add up, and the entire thing ends up looking messy and terrible to work with.
Was it Voltaire who said “Common sense is not so common”? I agree with your gardening analogy. It has an element of zen in it (just like gardening).