In case you're wondering why the Shade Tree Developer has been content free the last couple of weeks, I've been preparing for the talks that I gave at DevTeach this week. DevTeach 2007 is now in the books, so I'll trade in this strange Spoken Word tool for the more familiar Written Word and the wonderful magic of CTRL-Z. In other words, it's time to do one big ol' stream of consciousness post on everything I was thinking about this past week. I will surely get flamed for a bit of this, so stay tuned.
Enough rambling, here's what was trickling through my head after last week:
Hanging with the Cool Guys
These kinds of conferences are great mostly for the people you meet and interact with, and DevTeach was extraordinary in this regard. One of the things I miss about Austin is the constant entertainment that Bellware instantly provides in any situation.
I think I could easily spend all day talking to Jean-Paul. You should definitely take in his week long .Net training courses if you ever get the chance.
For months now, I've been looking forward to meeting the Israeli contingent, and we've even accused Bellware of helping stage the Agile track just to manufacture an opportunity to bring them to North America. Roy, Udi, and Oren (Ayende) are three of my favorite authors and blogger's. Meeting them in person was every bit as cool as I thought it was going to be. I love Ayende/Oren's passion and energy for development. Udi took some time with me to demonstrate his approach to DDD within an SOA. The dude's seriously got his head on straight. I got to take part in great conversations every single day on all things software related, but I think the most memorable episode at DevTeach was talking with Roy Osherove about our experiences being new fathers.
I was on the Microsoft & OSS panel moderated by Ted Neward. That's going to be one for the scrapbook (even if we didn't really get very controversial until the P&P stuff came up).
I also got to hang around a little bit with Rob Daigneau. Cool guy.
Seeing how the other half lives
I worry a little bit sometimes about living in an Agile echo chamber. I bet better than half of the RSS feeds I subscribe to are from Agile practitioners. I'm pretty sure that the majority of the people who subscribe to my blog either individually or through the main CodeBetter feed are already pro-Agile to some degree or another. I used to purposely read Hacknot (dropped because he doesn't write much and he's just too curmudgeonly) and Software Reality (dropped because they're just plain dumb) just to make sure I got a more balanced diet of intellectual content.
During the last day of DevTeach I purposely went to a talk in the architecture track about building application frameworks. I knew the talk was going to be far outside the realm of Agile thought, but I love talking software design so it sounded like an interesting talk. I just wanted to see how the non-Agile guys were approaching design and software construction and see if there is something else I need to be paying attention to.
From the first slide through the very end I wanted to jump out of my chair and argue with him on almost every single thing he put forward. The nameless architect (as I will refer to him throughout the rest of the post) lost me immediately. Let's see if I can remember all the things that bugged me (the sarcastic language is obviously mine). Build the application framework upfront. Divide the team into castes. The upper caste builds the application framework because they're more suited for the application design. The lower caste just can't be trusted, so we'll strait jacket them with the application framework to protect them from themselves. Liberally sprinkle your framework with all the hook methods you think you'll need later.
Honestly, I think the code he was showing as a sample had some design flaws. The code munged a couple concerns into one piece of code (always a big no, no in my book). He was using hand rolled factory methods and inheritance everywhere. I challenged him on that asking why he wasn't favoring composition and using an IoC tool to wire it together. He didn't particularly give me much of a response. I think I could have eliminated a whole bunch of his infrastructure code by merely using an IoC tool, and gotten a heckuva lot more flexibility out of the framework to boot. More importantly, the code wasn't testable -- and you know for me that testability is an almost mandatory prerequisite for being "good" code. The maxim "favor composition over inheritance" is probably older than I am, and it's borne out by my experience. I'm a little shocked to see an experienced architect so blithely ignoring this advice.
The end result is that this nameless architect and I could not possibly coexist on the same project. My longstanding opinion that traditional architects are useless if not downright harmful remains completely intact. I guess you wouldn't be slightly surprised to find out this guy is a big proponent of software factories as well. Of course, this guy had more people in his talks and better evaluations than me, so what do I know?
I'm always hearing that us Agile guys can learn stuff from the older, non-Agile software traditions. You always have something to learn from more experienced people (note that I did NOT say older), but that particular traditional architect could really stand to spend some time listening to what we Agilists have to say about design and how we work. The nameless architect was presenting what I would consider to be the best of 90's era software design, but we've learned plenty since then. The absolute worst part of that talk was looking around and seeing essentially no overlap in faces between the folks coming into the Agile track and the people I saw in the architecture track. I was horrified at some of the design advice this guy was spitting out, but the other attendees were rapt. We've got a problem there.
Software Factories - The CASE Tools Fiasco 2.0?
I'm not old enough to know the details, but I've heard plenty of stories about how people invested in CASE tools during the 80's and early 90's only to see the movement bomb. I do think there are some incremental gains to be had from Software Factories (I'm thinking of things like Jay Flower's CI Factory and the software factory-like project and code generation in Ruby on Rails). The problem is that I also think that Software Factories look a heckuva lot like BDUF wrapped up into new, spiffier clothes. My resistance mostly comes down to three things that I think are going to happen:
- People are going to freeze in Analysis Paralysis designing their own software factories outside of any real development work much the same way people waste so much time designing speculative frameworks today
- People are going to follow the software factory output no matter what. Again, this is BDUF at its worst. Design is never done. The Software Factory "guidance" and generation may work in most cases for your app, but I promise that there will be more than enough edge cases where the software factory pattern fails. You better be awake.
- People are once again going to waste time creating an environment where bad or mediocre developers can create acceptable software instead of investing in people.
Any older guys out there want to comment on the CASE tools from the 80's? I couldn't find any information on it at all, but I've heard plenty of horror stories.
By the way, there *IS* a Silver Bullet
After the first day I started to count how many conversations boiled down to an issue of safety versus power. It came up talking to a Sql Server guru who wanted to do data access through sproc's just to protect the database against the developers. It came up several times in discussions about using Aspect Oriented Programming and Metaprogramming. The nameless architect was trying to design a framework that forced developers into a strait jacket to prevent them from doing something wrong with the obvious implication that the developers just couldn't be trusted.
It comes down to a choice of:
- Enabling developers with the maximum in language and technical power and trusting them to do the right thing
- Making development "safe" for lesser skilled developers by taking choices away from developers
I read recently an argument that choice #2 does far more to hamper the efforts of your best developers than it does to make weaker developers more productive. I agree. So wrapping this whole stream of dialogue up, I'll say that there is a silver bullet(s), it's:
Skill. Knowledge. Experience. Passion. Discipline.
In other words, it's the people stupid! We need to invest much more in our people and the general skill level of the people doing the work instead of wasting so much energy on newer and newer forms of governance. We pay a very high price in productivity by not doing a better job of creating strong developers.
Why can't you trust your developers?
Since this came up soooo many times, I have to ask -- Why can't you trust your developers to do the right thing? If you don't trust the developers, what can you do about it? The hiring process is an obvious first step, but you've largely got the people that you've got. Can you work with them? Communicate better? And how do you know that the fault isn't with you? What is it that made you trustworthy? Can it be repeated for another person? Do you really think you're that special?
Or is the general population of developers so bad that this is hopeless and we really do need to worry about better and better ways to wring usefulness out of bad developers? I hope this isn't true, but it seems to be the prevailing opinion of the majority of people I've spoken to in the last year or so.
There are no smart guys, there's only us
When I write blog posts giving any type of advice I'm always waiting for some smarter, wiser developer to set me aside and say, "let a real expert handle this." One of the other Agile track speakers said to me that he just doesn't feel like he's that great, and he's always waiting for someone to call him out on that. A great developer I worked with in the past had a phrase for this feeling: "There are no smart guys, there's only us." There is no expert on the hill. No one out there knows everything and has all the answers. Look, I'm an elitist with a sizable ego, but I know there are plenty of things I don't know all that well and there are plenty of folks that intimidate me. You know what though -- they're just guys.
Not naming any names, but most of you know who I'm talking about, I joined an elite consultancy four years ago thinking that I'd get a chance to learn at the feet of the masters. I definitely learned a tremendous amount there, but I walked in as a technical lead from day one. Maybe that sounds strange, but that was a huge disappointment for me.
So what am I saying here? I guess I'm saying that
- No one's infallible and all knowing
- Don't sell yourself short compared to other people
To take one last shot at Software Factories, if there are no smart guys, why the heck should I trust some guy who doesn't know me or my app to do my design for me? I certainly don't trust that nameless architect to design software, so why the f*^%$ should I take a Software Factory from this guy?
XP environments are so much more fun
I sat in on the lunch time session on Pair Programming from a couple folks from Oxygen Media. Pairing is good, blah, blah, blah. What really struck me about their talk was how much I miss working in a dedicated Extreme Programming shop. I think XP teams and XP environments have far more energy and collaboration than traditional teams. You can just feel it in the room. My client environment is pure "cubesville" and the place is just flat out dead -- excuse me, professional. Work is work, but all things being equal I'd rather have an environment that allows me to have fun and be effective. Then again, being effective is fun to me even without having toys everywhere.
I've met 5-6 of the Oxygen Media team now in various events in NYC, and I gotta say that I think it's ironic that the "O" network, home of countless bad made for TV movies, is also home to such a cool bunch of programmers.
Microsoft, OSS, and the Patterns and Practices Team
I've said it before, and I'll say it again now, the negative relationship between OSS efforts and Microsoft proper is an opportunity lost for the .Net community. Yes, I do think the lawyers are largely to blame for MS's consistent resistance to open source tooling. The Java world just uses JUnit & Ant inside of their IDE's (I'm thinking Eclipse & IntelliJ). MS has to go and waste the time and energy to recreate NUnit and NAnt -- among others. Those resources really could have been better spent on something else. But no, because of the constant threat of litigation, MS studiously avoids any relationship with OSS tools that originate from outside Redmond.
A side conversation that I had after the panel is that innovation in the .Net world is almost entirely limited to our one single vendor -- Microsoft. OSS efforts, even when they're arguably more effective and higher quality, just can't make any inroads against MS's official position. In the OSS panel I brought up the Java community's far greater efforts in the OSS arena. Yes, the Java guys have more fragmentation, but they also have far many more choices and innovation comes from the community themselves. I mentioned to Ted Neward after the panel that I wanted very badly to jump into Ruby development last year when I was changing jobs because the Ruby community just has so much more energy and passion than .Net. Alas, being a .Net developer just flat out pays too much, and there's cool stuff coming down the turnpike for us without jumping ship (funny, I wrote this sentence before Hanselman's report from RailsConf).
Ayende took a shot yesterday at the Patterns and Practices team at Microsoft and the Composite Application Block that I thought was a little bit harsh. Chris Holmes fired back and called him out it. Ayende responded. Udi wrote a very reasoned opinion piece about the same subject called Why I don’t worry about the Patterns and Practices Efforts. I'm going to come in somewhere between Ayende and Udi.
In our OSS in the Microsoft World panel the P&P team inevitable came up, since their work borders on open source and much of their work directly competes with OSS solutions. Both Ayende & I made some criticisms of the Patterns and Practices team and their work. I think the P&P team's framework products are hampered by the fact that these tools are written in a vacuum outside of any one project or group of projects. It's speculative design. I'm very strongly in the camp that says frameworks should be harvested and grown, not built. Another thing, it's hard to create innovative ideas on demand the way P&P probably has to work. In Mario Cardinal's session on Test Driven Architecture, he talked about "A ha!" moments where a sudden design realization leads to leaps in design quality. It's similar to Eric Evan's "breakthrough" idea from DDD. I guess all I'm saying is that the P&P has a very difficult job in some respects.
I kind of wish the P&P team wasn't necessary, but they are. Like it or not, they have a vastly more visible pulpit to teach design principles and push better tools than any one of us here in the blogosphere. I'm not wild about the tools that they produce and I've almost completely managed to avoid using them, but their work on explaining the underlying patterns of the tools is far more important than the tools themselves.
I do wish the P&P team would reach out much more to the OSS community. ObjectBuilder in particular probably could have been a better tool if they'd reached out and asked questions or at least researched existing tools instead of recreating the wheel. I'd also like to see the P&P team occasionally feature OSS tools. I.e., if you like ObjectBuilder, try Castle Windsor, StructureMap, Spring.Net, etc.
I'll leave you with this thought (from me):
The Patterns and Practices team is a little beacon of Agile light in the Microsoft sea. Yes I don't think that many of the P&P solutions are really all that great, but I want the P&P team to succeed. A strong, visible P&P team benefits us greatly. The P&P team is making it easier for me to use the techniques like Dependency Injection and TDD on client engagements. That's a win.
You don't need to take the CAB
I might have helped spawn the Ayende/Chris Holmes thread on the CAB with this bullet point taken from my talk on WinForms design patterns - "Psst. You don’t need the CAB to build large, maintainable WinForms applications." I meant that statement very literally, but even if you're using the CAB it's important to understand the underlying patterns and concepts first. I know there was a feeling among many of the Agile track speakers that the core design concepts are far too frequently skipped en route to memorizing the API's. You'll be much more effective with the CAB itself if you understand what the CAB designers were trying to accomplish and why the screen responsibilities are split the way they are.
At the end of this, I just don't think the CAB holds much value for me. Granted I haven't used it in anger, or really studied it all that much. Part of that is because every time I look at the CAB I see all kinds of unnecessary complexity that results from trying to be so generalized. Any framework that requires me to wrap my application around the framework has to cross a very high bar of value added to make me use that framework. I sincerely think that I can accomplish a solid separation of concerns and even pluggability with my own code and an API who's semantics reflect my application in specific, not a CAB abstraction.
Chris Holmes asked the rhetorical question "how long would it take to duplicate the CAB yourself?" The answer is that you don't. You grow something during the execution of your user interface features to support your functionality. If you have a strong understanding of the underlying patterns like Model View Presenter, synchronization options, Application Controller and Application Shell, and Event Aggregator's, it's pretty likely that you can build something that works better for your specific application than the one size fits all CAB. Wiring pluggable UI elements together is relatively simple with the usage of an IoC tool.
And yes Chris, I'd much rather use my own fully-featured StructureMap tool than deal with the very limited ObjectBuilder DI tool embedded inside the CAB. Guilty as charged.
I thought my WinForms patterns talk went well enough to get reused, but if I get, let's say 3+ comments asking for it, I'll convert that content to a set of blog posts along a "Build Your Own Customized CAB in 24 Days" theme to try to prove that building your own MVP infrastructure is a suitable task for mere mortals. The sample code is mostly written, so it's not that much work.
What's important?
About midway through DevTeach I realized that I hadn't managed to attend any of the sessions on newer technology. I wish I'd managed to get to the WF/WCF/WPF talks, but I'm not too concerned because the content that I saw was very good (and besides, I was heads down doing last minute code samples for my talks). The talks that I *did* attend were largely on subjects that I think are more core than API's. Configuration management, what to test and how, design patterns, design concepts, things that apply to every single project you'll undertake. Yes Linq and WCF are sexy, but I bet it won't improve ROI as much as improving your knowledge of software design in general.
C# 2.0 today is starting to feel like VB6 in 2001
In the spring and summer of 2001 I was working on a system that included a configurable workflow engine being coded in VB6. I pushed VB6 to its very limits trying to make it behave like a fully OOP language. VB6 felt limiting. C# came along with full OO and multi-threading. I felt empowered. Fast forward to today, and C# 2.0 is feeling limiting to me. I'm wanting to write more fluent interface code, and C# will do it, but it's bulky compared to other languages. I'm wanting more functional language support, but the 2.0 anonymous delegate syntax is far, far too verbose. I'm finding all kinds of uses for metaprogramming, which is far beyond C#'s abilities. Ayende mentioned wanting "missing method" type effects in .Net. It's time to move on. C# 3.0, or better yet, IronRuby, just cannot get here fast enough for my taste. Give me sharp tools thank you, and leave the safety scissors for someone else.
Challenging the Notion that Visual Programming is Good
I think the .Net community as a whole has a dangerous set of blinders on when it comes to visual programming. My nameless architect ended his talk with a quick demonstration of MS's new tools for defining a DSL modeling language for your tool. If you haven't seen it, it gives you a graphical design time tool that allows you to create UML like models that generate code. He made a whopping assumption that was taken in hook, line, and sinker by the audience -- it's better because it's graphical. Is it really? And compared to what? For far too long, from Visual Basic, we in the Microsoft camp have worked on the assumption that visual tools and better design time support automatically equates to productivity. For our own good, we need to collectively challenge this assertion about the supposed superiority of visual programming and learn about code centric techniques that might lead to better productivity and far better maintainability.
ThoughtWorks is Busy
From a distance, I'm enthusiastic about some of the things coming out of ThoughtWorks right now as they seem to be reinventing themselves just a little bit (NOT excited enough to even consider going back and traveling every single week though). While I was at DevTeach I got to see a very brief demonstration of Mingle, the new Agile project management tool from ThoughtWorks Studio. Jeremy's in depth review from that 10 minutes -- Mingle rocks! It mimics the Information Radiator motif you get from a physical representation in an electronic form. I'm using Jira & Confluence at my client, and I've used early versions of TargetProcess (for about a week before we blew it off), but Mingle already feels more "right" to me (but I am ex-TW and it's built for their style of working, so take that with a grain of salt).
Just as an aside, Mingle is written in Ruby on Rails, but running on JRuby. Do you remember when .Net was the multi language, single platform virtual machine, and Java was the single language, multi platform vm? It's looking more and more like each VM is going into more and more directions. That can't help but be better for us all in the long run.
JP gave ThoughtWorks studio a bit of link love too.
Entity Framework
I'll say this very briefly because I've already written negatively about the Entity Framework, and nothing substantive has changed since then. The Entity Framework is clearly a challenged project right now, and it's obvious that they're getting pulled in a lot of different directions, most of which I simply don't care about. When we went to the EF focus group it was immediately hijacked by the data centric guys as a forum to vent over EF's support for sprocs. Since I largely zoned out when they said Stored Procedure, you'll have to research what they were talking about on your own. The point being that they aren't going to be able to make everyone happy, and I think it's pretty likely that other voices will be much louder than mine when it comes to the feature prioritization of EF.
NHibernate just celebrated a new release. I'm thinking more and more about how to use iBatis for places where the database either stinks or you need to utilize the database capabilities. Because of the wonders of OSS, plus some solid commercial tools for persistence as well, I'm just not all that concerned about whether or not the Entity Framework ever ships right now. Unless a client forces me to use it just because it's from MS of course, then I'm going to care:(
Ok that's enough. I'm going in to work this morning for the first time in a week. I'm expecting to be just a little bit buried for awhile.