Why structure matters
•Download as PPTX, PDF•
0 likes•13 views
The importance and cost implications associated with software structure.
Recommended
Recommended
More Related Content
What's hot
What's hot (6)
Similar to Why structure matters
Similar to Why structure matters (20)
Recently uploaded
Recently uploaded (20)
Why structure matters
- 1. Why structure matters Paul Hickey Director & Co-founder paul.hickey@structure101.com
- 2. ”Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test…” Ray Ozzie, former-CTO, Microsoft
- 3. ”The first thing we must understand about complexity is that not all complexity is equal. And the complexity on which most people focus is probably the least complex complexity of all” Roger Sessions, The Cancer of Complexity
- 6. Martin Fowler • "I thus divide software quality attributes into external (such as the UI and defects) and internal (architecture).” • “High internal quality reduces the cost of future features, meaning that putting the time into writing good code actually reduces cost.” • https://martinfowler.com/articles/is-quality-worth-cost.html (May 2019)
- 7. “Well structured software is delivered in half the time, at half the cost, and with 8x less bugs” US Air Force
- 8. Microsoft research “Up to 78% of a developer’s time is spent understanding code”
- 9. Why structure matters… • Developer productivity • Developer guidance • Reduced build times • Improved estimates • Risk & delivery dates • Focused testing • Reuse & extensibility
- 10. Cycles explode complexity! CCD = (1*1) + (7*2) + (8*3) + … = 148 CCD = 332 = 1,089!
- 11. Findbugs – a real world example 0.8.0 June 20040.8.7 April 20050.8.8 May 20050.9.3 September 20051.0.0 June 20061.3.5 September 2008
Editor's Notes
- I haven’t used this slide before so I’d like to know what you think. Does this resonate with you? It resonates with me. “it sucks the life out” in particular. I believe it resonates with a lot of development teams, not just developers, but managers and business stake holders too. We feel it, but we cant quiet put a finger on it(or intangible), nor articulate it. It’s why teams and the business stake holders feel frustrated with the pace of development. But what’s at the heart of the statement?
- Sessions is one of the leading experts on software complexity. Would you necessarily associate it with the structure of your codebase? My job today is to convince you, it’s all about structure. Mind sized chunks of code that are not all mutually dependent.
- Is this data center a good metaphor for your codebase? Remember when you were a kid? Your parents always thought you - clean your room, keep your desk tidy. Why? When we are organised we get more done. It’s as simple as knowing where to find things the things you need for the task at hand, and having clarity of thought. Which of these data centers would you rather work in?
- Is the data center a fair analogy? Is code like that? Yes, and then some, getting exponential worse with the size of the codebase. 2 examples, both hugely successful open source projects of similar size, approximately 400kloc. First, is Spring. First started in 2003, has since had a torrent of new web technologies thrown at them which they have needed to add support for, and which they’ve done so very successfully because they maintain a clean structure with no tangles so they know where to add new functionality. Consider when they started there were 30+ commercial and open source application frameworks on the market, yet they destroyed the competition. The only others left standing are perhaps Jboss and legacy. Note also the graph of Spring is surrounded by a grey box indicating a “cluster” (cohesive code) where all the dependencies flow down, there are no cycles. Moving on to the next highly successful open source project, which will remain nameless. It is surrounded by a red box indicating all items in the graph are involved in a tangle. Everything uses everything else, there is no structure. Make a change you must test everything. It goes to show you can be very successful even with a messed-up codebase but at what cost? The maintenance costs on the second must be astronomical, while knowing how and where to add new capabilities must be challenging at best. Which codebase would you rather work on? Which codebase does your codebase more closely represent? Do you even know? This is the key, your structure is sucking the life out of you, and it’s intangible. It doesn’t need to be, but you do need tools to give you a window into your structure. Open source tools like Jdepend and ArchUnit. Commercial tools like Structure101, Sonargraph, and Lattix.
- If I asked everyone in the room to write down their list of top 10 software development influencers in the world, the chances are Fowler would be on everyone’s list. So what does he have to say on the subject? In a recent blog post on software quality he divides quality into 2 categories - internal and external. External covers defects and the quality of your UI (i.e. what’s visible to the end user). With internal your customer doesn’t care, it doesn’t impact their use of your product, hence the business tends not to care and so it tends to get ignored. But Fowler concludes the business is foolish to ignore it as it is proven in reduces cost in delivery new features. And likewise your customer should care, as it impacts your time to deliver your capabilities. But by how much does it reduce costs?
- Even if it’s only half true! Only the US Dept of Defense could afford to undertake such a study. Where they took a 50kloc codebase, gave it to 2 equally skilled teams, getting the first to refactor it’s structure, and then asked them to extend and maintain. Leading to their conclusions.
- This is another one I like because it’s much more self-evident. And it’s another jaw-dropping statistic. Looking around you would be hard pressed to find anyone claim a developer spends less than 50% of their time reading code. What is a developer doing when trying to understand code? Not exclusively but mostly they are chasing dependencies. And the visualization aspects of Structure101 alone make developers more productive in this task. And that’s before the real benefits of improved structure kick-in.
- Developer productivity Smita story Developer guidance One of the MDs at a major Wall St bank said to me that he wanted to be able to leverage the experience of his senior developers to put what he referred to as “guard-rails on the autobahn” Improved estimates Back in the 90’s my co-founder, Chris, was the architect responsible for the tooling of a team of 100 developers that built the software for the robot arm for ISS. A billion dollar project! Management relied on him for estimates but Chris realised when you don’t fully understand your real as-is structure estimates are a bit ”finger in the air” like. That was the prompt for setting up Structure101 – it was the itch he needed to scratch. Focused testing European bank with army of testers story Reuse & extensibility Mars Insight Division of labour
- If you are not already tracking your software structure then the chances are when you lift the lid you will see it’s more like the second data center than the first.. John Lakos CCD is Cumulative Component Dependency Key phrase – cycles explode complexity & torpedo costs Start with an extreme but fabricated example What you are looking at here is a “layered structure map”, util does not use anything else in the system, everything on the second layer uses util, and everything on the third layer uses at least one item in the layer below and so on. In this example, one simple addition to the code adds a dependency that makes it an order of magnitude more complex. CCD is Cumulative Component Dependency – a metric devised by John Lakos in one of the most successfully C++ books of all time, Large-Scale C++ Software Design. When one item depends on a second, it really depends on all the items that the second item depends upon, and that they depend upon, etc. For instance an item can be impacted when anything in its dependency closure changes. The CCD of a system is the sum of the dependencies of every item in the system
- When limited time speed thru this one A healthy start – they knew what they were doing May 2005 is when the rot really started to set in. But you cant manage what you cant see, & they had no visibility. And this from a team that cared deeply about software quality. If you are not currently delivering features as fast as the business expects, chances are your structure is having a big impact on your velocity. Show the business your as-is structure and they are much more likely to be supportive of enabling your team to address the problem.