Notes by Bill Pollak, Peter Foldes, and Jack Chen
Dave Thomas, CEO, Bedarra Research Labs
The Intimate Relationship Between Architecture and Code: Architecture Experiences of a Playing Coach
We have architects, but there is still a problem. This can’t be us, because we’re all great. We went to a conference.
No one wants their software to stink. I’ll talk about things I think are wrong.
Why does our architecture smell?
It must be the developers who are at fault. They do things wrong. They don’t listen to advice, understand what we do. They don’t conform to architecture guidelines, styles, patterns, and UML code, don’t refactor.
Managers devalue architecture. The more you get into IT, the more you don’t need architecture.
Are profit-driven organizations the problem? Quest for profit leads to near-term gratification, not enough time, encouragement of technical debt
If architectures are part of the problem, then we need to be part of the solution.
Clearly no problems with us, the code is right, it was just the requirements that were wrong. We are dismissive of new approaches such as functional programming. (“I have seen those brackets in high school, I’m not doing that.”)
Part of the problem is us—disparate views from ivory tower, dismissal of new approaches, faith in models not in code. View of architecture as just guidelines, styles, patterns. “I’m post-technical,” we say proudly. = This means, “they pay me more money to know what’s not going on.”
Enterprise architect = an oxymoron? Takes up so much time. Good idea to have an inventory, so EA is a good catalyst, but it gets in way more than it helps and creates many arrogant prima donnas.
Models are useful, but they’re not the architecture. Diagrams usually have no semantics, no language, and therefore tell us almost nothing. There are no semantics in UML, or meaning, or exchange, just a picture. UML has to be one of the most useless models in existence. It usually just produces a picture that 90% of the time you can get directly from the code (automated) or an outliner. Hibernate puts nice data-access code in the middle tier while sucking out performance. For what? Modeling is important, but models that are important are equations, code, mock-ups. We need more storytelling. Models tell a partial story. A model is an abstraction of the real thing. It’s a partial description, not the thing that gets shipped.
Components are a good idea. Frameworks aren’t. They are components that were not finished. They inject dependencies into code. Only experts know how they can use a framework. There is a recent study that open-source Java frameworks only had 25% of their code executed ever. Components should be things that exchange value, not objects. Only experts know how to work inside a framework.
Agile: “I got my cards, and my code, and I just let the architecture emerge. Architecture just emerges? Come on!” We make pigs of ourselves every sprint, then later we worry about technical debt. Because we believe in emerging architecture, around sprint 5 comes the technical debt cards. If you want to make technical debt fast, use naïve Agile. “But you said it just works!” We have no serious refactoring tools or techniques for large codebases; it doesn’t scale.
Naïve Agile leads to technical debt. Agile talks about aggressive refactoring. We have no serious refactoring tools or practices for dealing with large code bases.
Essential architecture: You can either get nice architecture and no features or vice versa; take your pick. Acceptance criteria are emerging. In essence architecture is interfaces and components, and features that touch interfaces. Without versioning the interfaces, you cannot get a current view of the architecture. Customer pays for features. Set of acceptance criteria provides architecture invariants and quality. Key is to make those tangible and testable. Need a collection of stories or pictures to let you do this. If you don’t version the interface, you’ll never create real models of the code. If you have a simple story, that provides a shared vision of what is being developed. Styles, patterns, models are tools for telling the story, but they are not the story. Storytelling is how we really get to know architecture.
When you know what you’re doing and you have the experience, you can get pretty good at design. The problem is when you don’t know something, but then a group of people can come up with something smart. Small group of people in a room can do this—extreme design is something everyone can do.
Is “architect” a job or a role? It’s not a job, it’s a role. They need to be able to understand the environment, act as playing coaches, and read code. They need to know the essence of what’s going on. In the end it’s still hardware and software. If it’s too complicated, shoot the consultant and look for someone more useful. No matter the language, a mess is still a mess; you can smell code from a mile away.
Everyone should do a little to make sure the code works. Need to read code. Good architects have code on their hands. Architects should be capable playing coaches who can at least read developer code and pair with them. Post-technical isn’t an option for architects.
Biggest thing is that a lean software organization doesn’t need a big management structure. Competent playing coaches can build a technical ladder. The best plant managers are not at meetings, they are walking the floor. There should be no “architects,” just senior members of technical staff or distinguished engineers.
The best hockey teams have good management, but also outstanding playing coaches. We need to invest in experience, and we’re losing it quickly. We need a technical ladder with rungs in it. We need people who get paid, but not to go to meetings.
Good engineers build with passion and work hard at things they believe in or for executives they trust. See Drive by Daniel Pink. http://www.danpink.com/drive
Process used in Baderra, mostly copied from Toyota. There are four boxes (although Agile mostly like to thinks there is only one: development): envisioning, definition, development, and release engineering. Good engineers build wonderful products for managers they trust.
People doing Agile methods like it and don’t want to go back. It’s transparent and pushes out features. The problem is that it gets too hard to cut the stories so that a development team can do something with it. It’s amazing how many organizations claim their “agility” by how many Scrum masters they’ve certified. In most organizations, programming is a blue-collar sweat shop, but it pays well. We need a reasonable approach. The more code you write, the more you have to fix; the more you have to refactor, the more you have to fix. Agile, Lean, ISO 9000, TQM all come from same source.
Six Sigma is how you testify that you have a process that you didn’t do
Agile is doing the process but not documenting it. Agile that is real CMM level 4 has metrics.
- Codebase: defect density
- Artifacts and tracking them so management can’t push in features after a freeze.
- Survey the team for general health check.
Portfolio management: Most people can only do a small number of real things that are important. Lean: know your own capacity. As an executive the most important role is to pick the best wrong way to do things, work with people, and make a difference.
In engineering prototyping is honest work. In software, it’s making something that doesn’t work and probably won’t.
Good thing about agile is that it teaches software developers to estimate. When you’re building big [un]interesting things, it costs a lot, and you have to estimate early. Estimation is a distribution, anyone that gives you a hard date is wrong. Agile estimates in story points, so you won’t know what they’re saying. They’re estimating now and building confidence.
Key activity is called envisioning. Take the wishes, and turn them into acceptance criteria and requirements. If you have to have doors than you have too many requirements. Some techniques used, like house of quality (QFD) , low-fidelity prototypes (customers can actually buy using these).
Definition: Size and allocate the work. Agile teaches software developers to estimate (planning poker and wide-band delphi). Estimate is a distribution. Estimate early and often. Use risk windows to plan.
Put your architecture on the wall. Sort the backlog based on business value. DSMs are important, and use them at the beginning.
Speed and agility don’t come from objects or Agile. They come from change points and intervention opportunities to ship less code. There are teams and outstanding people and the selective use of them helps, but don’t expect to be able to teach that over the organization. The only way to accelerate software delivery is to deliver less software, selectively deploy a high-performance team, make a material change in the value chain to reduce the cycle time.
The identification of high-value innovation opportunities is a key architect responsibility.
Successful software development is about a winning culture. Encourage “fail fast, fail often.” Need to make things quickly enough to demonstrate quickly the things that don’t work.