- How well does your program do... well, whatever it does? -- A lot of people have trouble getting a handle on nonfunctional requirements like performance and reliability. I gave developers who want to get real, practical improvement a quick technique to help with this. (And like most great techniques, it uses index cards.)
- What makes architecture "better"? -- I take a stab at answering a basic question: what does "better" really mean when it comes to architecture? It's a basic concept behind quality, but it really helps to apply it to architecture, too.
When we were working on Beautiful Teams, I was really surprised to see just how much overlap there was between getting software teams to work well together and getting them to improve the architecture of the systems they were building. That was a big learning point for me. I really had those two areas, architecture and teams, in separate "buckets." It was really enlightening to me to talk to people whose opinions I really respect, and hear them draw a direct line between better software teams and better architecture.
I want to share a quote with you that helped open my mind to this. They're both from Beautiful Teams. The first is from our interview with Auke Jilderda. We talked to him because he's had a lot of success studying how those open source teams work and applying their lessons to corporate projects. (That's a favorite topic of ours -- it's why we wrote What Corporate Projects Should Learn from Open Source.)
The reason I like this interview so much is that Auke really showed how great practices borrowed from open source can have a big influence on software design. He led an effort to take the successful practices used on open source projects and help software teams teams across his company learn to use them. It was really successful. But what I thought was very interesting, especially from an architecture standpoint, is that adopting open source practices -- improving openness between teams within the company -- had a profound effect on how his team architected their software. And that's where this excerpt ends up.
Andrew: [So] you came up with the name "inner source."
Auke: That worked very well, just giving it a name. I did all of the rounds within the company's internal conferences, where every single conference--whether it was just the research department or the whole of the company--telling the story of inner source was creating a buzz within the company. And it's a huge company, so that was a lot of work, creating a buzz and getting visibility. That worked very well. And of course, every chance I got I talked about it, and talked to especially those product teams around the product family program. Doing that for about a year or so, that started paying off. They started crediting the inner source initiative with that positive influence. And then they started to take it seriously.
In the meantime, we also introduced much more openness. We started by making all the source code available, but then there are next steps to be taken as well. We also started making the communication open--not just the mailing list for support, but also for developers. So, all of the development discussions also started being on a mailing list. If you're on a product team, now you can follow the discussion the developers have. We made the tracking information much more accessible. And we introduced something that we called snapshot builds. That had been quite a battle as well with the product family team, because it's considerable work to provide a weekly snapshot build, or a biweekly one. Basically, you build a version of the whole set of common components to make it easy for the people around the product teams to work with and adapt a very recent version of the common components, in turn making it more likely for a patch to make it back into the main line. That's what we pushed through as well. And once that started being part of the standard process, once we had that automated, it also made a big impact because it made it easier for people to start adapting and, with that, using common components and increase the chance of a patch being accepted back into the main line.
Another thing we added was to write some key documentation. Really successful open source projects always had three distinct levels of documentation. They call it different things at times, or organize it differently, but they had three distinct levels. One is a README: what is the project about, and who's involved. The second level is how you start using it: how you install it, what are the runtime dependencies. It doesn't explain it in extraordinary detail. It just says, "This is how you typically start using this." And the third level is contributor information: how you build new versions of the software yourself, what kind of dependencies you need, and how you contribute something. Note that this fits the three distinct types of people involved in a community: users, contributors, and committers. The README helps people decide if they want to become users, the install information helps people to become users, and the contributor information helps a user become a contributor.
That's what we see in successful open source projects, and we copied it inside the enterprise. And again, that made a big difference. For instance, when I first arrived with the teams, I took a standard development machine from that same department, and tried but couldn't get it to build. Which meant a developer at a product team would most likely not be able to get it to build either--there was clearly information missing. I had to ask three different developers before I got it working. We worked out a short document that clearly defined the runtime and build-time dependencies and outlined how to build and run. It all goes back to making it easy to use and adapt to your needs.
Jenny: So, making your company more open changed the way the teams did their work. But did it have any real effect on the way they designed their software?
Auke: There is a fundamental difference between open source and the enterprise. In my opinion, open source actually found out how to properly reuse software, while enterprises are still learning it. What you see in the enterprise is that they try to design for reuse. Theoretically, that is great, but typically you don't know and cannot foresee exactly how software will be reused. The only thing you really know for certain when you start building software is that it's going to be different than you think, and it's going to be basically used differently and work differently than you had initially envisioned.
-- chapter 8 of Beautiful Teams (O'Reilly, 2009)
The interview continues with a discussion about designing for reuse, and how the open approach can change the way you reuse code in different ways. Auke goes on to talk about what he calls the use-use-reuse pattern: instead of designing for open-ended reuse, build your architecture for the use you know about it, adopt it to a second use, and then figure out how to generalize it.
That's a really powerful idea, and I was really surprised to see the connection between practices focused on team communication and quality and improving architecture. It's one of those gems that I really value from our work on Beautiful Teams.
You can read more of Andrew's posts at Building Better Software.