When I go to conferences I see a lot of talks that follow the general theme of I/my team/our product/our process/this tool is wonderful. In contrast to that, I’m giving a talk Friday at Codemash entitled “Lessons Learned from a Long-Lived Codebase” about my experiences with the evolution of the StructureMap codebase in its original production usage in 2004 all the way up to the very different tool that it is today. Many structural weaknesses in your code structure and architecture don’t become apparent or even harmful until you either need to make large functional changes you didn’t foresee or the code gets used in far higher volume systems. I’m going to demonstrate some of the self-inflicted problems I’ve incurred over the years in the StructureMap and what I had to do to ameliorate those issues in the hopes of helping others dodge some of that pain.
Because StructureMap is such an old tool that’s been constantly updated, it’s also a great microcosm of how our general attitudes toward software development, designing API’s, and how we expect our tools to work have changed in the past decade and I’ll talk about some of that.
In specific, I’m covering:
- Why duplication of even innocuous logic can be such a problem for changing the system later
- Abstractions should probably be based strictly on roles and variations and created neither too early nor too late
- Why your API should be expressed in terms of your user’s needs rather than in your own tool’s internals
- Trying to pick names for concepts in your tool that are not confusing to your users
- For the usage of any development tool that’s highly configurable there’s a tension between making the user be very explicit about what they want to do versus providing a much more concise or conventional usage that is potentially too “magical” for many users.
- How the diagnostics and exception messages in StructureMap have evolved in continuous attempts to reduce the cost of supporting StructureMap users;)
- Using “living documentation” to try to keep your basic documentation reasonably up to date
- Organizing whatever documentation you do have in regards to what the users are trying to do rather than being a dry restatement of the implementation details
- The unfortunate tension between backward compatibility and working to improve your tool
- Automated testing in the context of a long lived codebase. What kinds of tests allow you to improve the internals of your code over time, where I still see value in TDD for fine grained design, and my opinions about how to best write acceptance tests that came out of my StructureMap work over the years
- Lastly, the conversation about automated testing is a great sequeway to talk about the great “Rewrite vs. Improve In-Place” discussion I faced before the big StructureMap 3.0 release earlier this year.
This is a big update to a talk I did at QCon San Francisco in 2008. Turns out there was plenty more lessons to learn since then;)
I’d be willing to turn this talk into a series of more concrete blog posts working in the before and after code samples if I get at least 5-6 comments here from people that would be interested in that kind of thing.
18 thoughts on “My Talk on Long-Lived Codebases at Codemash”
I’d definitely be interested in a series of posts – watched the recording of a talk from NDC in 09, I think, useful stuff
I would rather see it at CodeMash, but since I wont be attending this year, I’d love to see the blog posts with the information.
Please write it as a series of blog posts, or at least get the talk videoed. Always enjoyed reading your blog posts.
+1 for a blog post series.
Count me in as a vote for a blog post series – does this put us over the “5-6 comments” count now? 🙂
+1 for blog posts – definitely 6 now…
yes it certainly does now
+1 for blog posts
I too would appreciate anything else you write on this. I always learn something from your posts.
This is a really good idea for a talk at any event, and inspires me a bit. I need to think about the stuff I’ve been involved in over the years, and where the overlap is. Your list definitely has some things in common too. I was just trying to come up with something not in the “this tool is awesome” talk realm!
+1 for blog posts
I will enjoy reading that series of blog posts if they exist.
Since you explicitly asked for a plus one here is the plus one
+1 for blog posts!
Ok folks, that’s more than enough encouragement. I’ll have the first one out tomorrow maybe;)