RIF Notes #27
“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” – Melvin Conway
- Revisiting Conway's law – “if you want cohesive and decoupled systems, put different teams at work on each of them, so that the communication structures of the teams resemble what you want to achieve with projects…Segregation of responsibilities starts by our own work organization"
- Software Structure Can Reduce Costs and Time-to-Market – “the structure of software largely determines how long it takes and how expensive it is to develop, test, extend, and maintain a software system…the structure of software largely determines how long it takes and how expensive it is to develop, test, extend, and maintain a software system…when the structure of the code base significantly impedes the time of subsequent deliveries of the right features, a business’s competitive agility is lost and the Return on Investment on the software goes wobbly”
- Why Projects Don't Make Sense – Projects with discreet beginning and end dates is challenged. Acknowledging that software is never done suggests that ‘projects’ are not a good match whereas a standing teams might be better.
- The Corruption of Agile – Suggesting that the productized and cultish practices of Agile have led it astray.
- Secrets of Handling Support in an Agile Team – “Reserving capacity is not enough. So the dev team dedicates one developer per iteration for support work. The developer handles all support tasks”
- Hordes Of Novices – Uncle Bob asks “Do you really get software built faster and better by throwing ever more barely competent bodies at it? Is the software problem really a raw manpower problem? Is coding the same as bricklaying? More bricklayers means more bricks and more coders mean more code; but is more code what we want?”
Comments
Post a Comment