Pivotal assumption - “An assumption on business case, priority, minimum viable offer, or requirement that if false will fundamentally change designs, deliverables, or timelines.” In my post on how organisational factors increase the bad impact of architectural debt, I referred to how the lack of clear business objectives and priorities slow you down and prevent important … [Read more...] about Using Pivotal Assumptions to Increase Velocity
architecture
The Changing Development Organisation: The Software Architect
(intro to this post on devops) It has been a busy few months. Since my last post I have transitioned to a new role as part of day to day development (see linkedin.com/in/greger for more details) in the Collaboration Infrastructure Technology Group (UC, telephony, telepresence, conferencing, etc) in Cisco. Earlier, as part of Office of the CTO, I influenced the medium to … [Read more...] about The Changing Development Organisation: The Software Architect
Distributed System Architectural Debt: protocol, layering, and flow debt
This post is the second post on distributed system architectural debt. If you haven’t read the first post, I recommend that you read about why you acquire architectural debt and how feature-driven architecture development is a main contributor. I also there cover “abstraction debt”, the first of four types of architectural debt I cover in this series.The second type of … [Read more...] about Distributed System Architectural Debt: protocol, layering, and flow debt
Distributed System Architectural Debt: The mother of all debts! And it’s feeded by features…
In my previous post, I asked the question “Can you get 4,000+ engineers to work together?” The answer is, in the traditional “together sense”, an obvious no! However, just like ants are building an ant hill, not by talking to each other, but by each ant following a set of rules or behaviours specific to their role and by using simple signals, you can get way more … [Read more...] about Distributed System Architectural Debt: The mother of all debts! And it’s feeded by features…
Can you get 4,000+ engineers to work together?
I still have one or two posts I want to do on a multistream-enabled, scalable video architecture, but I have for some time also wanted to write a series on the technical scale challenges in a large, distributed engineering organisation. The fundamental problem is that the classic command and control approach with centralised planning, coordination, and program management breaks … [Read more...] about Can you get 4,000+ engineers to work together?