But I still don't know if I really like him.
From his infamous post on node js, I proceeded to many other entertaining and flowery articles. Worth a read even if you end up thinking he's probably just another obnoxious American prick (which wouldn't be very fair of you if you've never met the guy).
One post that has stuck in my mind is one about process and software development methodology (and the virtue of almost-not-having one). I think he may have a point here. I know he howls and whines like a starving dog in heat but he's right - much of this corporate bs "standups", "backlog lists" etc. really does not work very well. It might work ok in an idealised environment, but I've yet to see e.g. a Scrummaster run "proper" scrum, or even a variant which preserved any of its virtues in a corporate environment. At least in my time in London... It doesn't matter if it's a startup, a bank or an educational firm, large or small, they all end up relying on meaningless process because it lends structure, but that structure itself has no further meaning and uses up large amounts of time and emotional energy.
The same is true of mountains of unit tests and associated mountains of endlessly injected services into classes that would be small, simple classes in the absence of trying to shoe-horn TDD into the mix. Don't get me wrong - I love a bit of TDD, and I feel safer with some of my projects knowing it's there - but not usually in corporate projects. In those situations, you have a huge solution drowning in endless layers of redirection, specialised handling and most importantly - endless mapping of one layer's entities to another layer's entities - all of which, I suppose, should be TDD'd. So you write reams of tests for mapping entities (yes I know about automapper) which represent logic which shouldn't be there in the first place. (yes I know about BDD). All the unit testing in the world doesn't compensate for a lack of good architecture, and a lack of understanding of the virtues of small, autonomous systems communicating with messages (as opposed to a large stack of crud).
Why do businesses keep building these crap systems? Is it just a lack of bravery to separate things into meaningful discrete units? Are we that afraid of deployment? Is it too much to ask that "the website" isn't just one thing (or two if you count the database)?
Well, I'm not up for it any more. I will be asking about architecture in all future interviews for work I take on. What I want to know is - "how do you divide your systems up into meaningful subsystems?" "how to those subsystems communicate with each other?"
From his infamous post on node js, I proceeded to many other entertaining and flowery articles. Worth a read even if you end up thinking he's probably just another obnoxious American prick (which wouldn't be very fair of you if you've never met the guy).
One post that has stuck in my mind is one about process and software development methodology (and the virtue of almost-not-having one). I think he may have a point here. I know he howls and whines like a starving dog in heat but he's right - much of this corporate bs "standups", "backlog lists" etc. really does not work very well. It might work ok in an idealised environment, but I've yet to see e.g. a Scrummaster run "proper" scrum, or even a variant which preserved any of its virtues in a corporate environment. At least in my time in London... It doesn't matter if it's a startup, a bank or an educational firm, large or small, they all end up relying on meaningless process because it lends structure, but that structure itself has no further meaning and uses up large amounts of time and emotional energy.
The same is true of mountains of unit tests and associated mountains of endlessly injected services into classes that would be small, simple classes in the absence of trying to shoe-horn TDD into the mix. Don't get me wrong - I love a bit of TDD, and I feel safer with some of my projects knowing it's there - but not usually in corporate projects. In those situations, you have a huge solution drowning in endless layers of redirection, specialised handling and most importantly - endless mapping of one layer's entities to another layer's entities - all of which, I suppose, should be TDD'd. So you write reams of tests for mapping entities (yes I know about automapper) which represent logic which shouldn't be there in the first place. (yes I know about BDD). All the unit testing in the world doesn't compensate for a lack of good architecture, and a lack of understanding of the virtues of small, autonomous systems communicating with messages (as opposed to a large stack of crud).
Why do businesses keep building these crap systems? Is it just a lack of bravery to separate things into meaningful discrete units? Are we that afraid of deployment? Is it too much to ask that "the website" isn't just one thing (or two if you count the database)?
Well, I'm not up for it any more. I will be asking about architecture in all future interviews for work I take on. What I want to know is - "how do you divide your systems up into meaningful subsystems?" "how to those subsystems communicate with each other?"
