Improvement

The Wild Goose Chases of 2011

Improvement

I spent a lot of time last year trying to learn a lot about everything I could in terms of the latest development fads (other than Agile – I think I’ve flogged that horse to pieces). I figured I needed to learn Ruby, Rails, JavaScript, Node, jQuery, Backbone,… Part of the department is rebuilding a PowerBuilder application that needs to stay a thick client using WPF, so I learned a bit about Caliburn Micro. I found a little time to dabble in CQRS, MicroORMs, RabbitMQ, and MassTransit as well, but I didn’t focus on them too much.

The net result, come the holidays in December, I was feeling quite burnt out. So much so that I pretty much ignored software for a bit. January started and I felt better, and then I went to CodeMash, and that helped a bit. But the thing that really snapped me out of my funk was the realization last week that while I should know the basics about everything I can, I can’t know everything in any real depth. I have to have something I specialize in.

I’ve always been a fan of the generalizing specialist theory espoused by Scott Ambler. The problem was, I was spending all of my time generalizing. Part of that was an occupational hazard – I am tasked with figuring out the general direction for the technology and architecture of our product suite going forward. In order to do that, I needed to evaluate the suitability of some of these things. But I certainly didn’t need to dive into all of the shiny tools and toys I did – some of it didn’t matter at all. Some of it could have been delegated to someone else.

So now, as I step away from the fire hose that I’ve spent the last year trying to drink from, I realize what I need to do. I need to focus on the things that I know well, that have gotten me to where I am today. Sure, I still need to occasionally play with other technologies. But that can’t be the focus of my software development life. By diluting myself across these things, I haven’t really helped anyone, especially myself.

Now that I have that sense of clarity, I think this year will go much better…

Don’t take any wooden nickels, part 3

Improvement, Techniques

So don’t trust consultants and don’t trust Microsoft (and by Microsoft, I really meant any vendor’s guidance). And it’s more a case of trust, but verify. But I digress…

Open source software can be a great solution to a problem you need to solve. Finding the right tool or library can cut precious time off of your schedule and greatly decrease your maintenance costs. Of course, if you aren’t careful an OSS solution can be the anchor that drags your project down to a watery grave.

As I said about consultants and vendors in the other posts in this series – it’s your responsibility to explore the in’s and out’s of the open source solution. Will the license work for your business model? Is it well supported? Is it a fairly good match to the way you and your team build software? Lastly make sure it really is better than the alternatives.

The alternatives you have to consider are commercial solutions and building it yourself. If you need to figure out how best to carry out that evaluation, there are plenty of sources out there to guide you. But that’s another show. If you can’t wait and need some pointers I use, feel free to email me.

The point of this series is that software is a tricky game. There is no one best solution that will apply to all problems, not even for a small related subset. Carefully consider the options. Learn from multiple sources. Read articles and books about things outside of your stack of choice. Heck, read about things not directly related to software at all (I’m a sucker for pop econ and statistics books – Freakonomics and Drunkard’s Walk are very good books).

Don’t blindly follow.

Don’t take any wooden nickels, part 2

Improvement, Techniques

Microsoft Patterns and Practices is an extreme case of my theory about consultants. These guys appear to have never shipped anything that will be used by real users. That wasn’t always true. Early versions of the Data Access Block were quite useful. But then they started building examples that showed every possible facet and feature they could think of. And people started using these examples as guidance. Probably because P&P told them to.

The problem was, these things were too complicated for any real use and too complicated for a mere mortal (or even one of those rockstars. or was it ninjas?) to be able to extract just the little bits that could help them. And so people just started using these things whole hog, even if they only really needed 10% of the functionality. And don’t get me started on how big consulting firms (like the Big 6, or however many are left these days) love to use them as a basis for their lowest bidder projects that overrun schedule and budget…

What’s even worse is that typically these things do not follow sound software development principles. To them, OO is a typo where someone forgot to include the "W" (WOO!). People use these things as guidance to learn from. There’s an idea that there is nothing worse than to lead an innocent to sin. I’m not calling them evil or anything, but this guidance isn’t doing anybody who’s learning how to code in .Net any favors.

And of course, most sample code has this problem. In the sample code accompanying an article or a presentation, sometimes it is necessary to leave out the parameter checking and error handling code so that your point is clear. Its not the greatest thing, but its usually worth the tradeoff. It might be nice if maybe we started including the "well written" version in our sample code downloads.

The problem is, P&P ships these things as guidance. They implicitly say – if you write your code like this, everything will be great. And that’s probably true for version one but the omissions and issues of version one tend to live a long time. Not following good OO and development practices makes it hard to maintain and improve the application and that’s no fun.

Don’t take any one source as the guide for how you build software. Microsoft has provided a lot of very good tools and some very good guidance about how best to use those tools. But that guidance does not apply to every situation and some of it really doesn’t apply to any. Make sure you look at all sample code (or even open source project code) with open eyes. The author probably has a viable solution to a problem and it might even be your problem. But don’t assume it is the best solution for your needs.

Don’t take any wooden nickels, part 1

Improvement, Techniques

Shipping software is hard. Even if you are just packaging it up lightly so you can put it on a couple machines in Accounting down the hall, once it leaves your protected little world, anything can happen. And usually does.

And so we have TDD and BDD. Code reviews. Pair programming. Code coverage reports. Programmer testing. QC testing. QA testing. Performance testing. You get the idea – we have a lot of ideas about how best to make the transition of our software out to the real world as smooth as possible by making sure the software is good enough.

Good enough. That’s the key words here. Unless you have written a very trivial application, you will never ship something bug free. Think about that for a second. It’s depressing if you let it get to you. Now, think about some of the things that count as bugs – some of them are issues because the software doesn’t work the way the user expected. Or other things you couldn’t have possibly envisioned anybody doing with your software. It happens.

If you try to fix all of the possible issues, you will never ship. This leads me to a theory I’ve been toying with, the one that has to do with shipping software: Never trust a consultant who hasn’t shipped software in X years.

I haven’t decided yet exactly how many years. Maybe you just have to go with your gut. But the more I read from industry luminaries who espouse things like all code must be covered by tests that were developed in a TDD fashion or that you have to develop on the trunk so you can continuously deploy, the more I think that my theory might just be worth  something. 1

I’m not saying to forget about this advice. Its good advice, in theory. But don’t take it to an extreme. Extremes tend to cause pain.

1 In fairness, I’ve been a change agent at various points in my career. I know that sometimes you have to make an extreme statement (and follow through with it) in order to break old habits and effect change. Ask me about stored procedures sometime…

Unnoticed Improvement

Improvement

I ripped my rotator cuff playing racquetball. It’s a small tear, no surgery needed. I did it back in March. It took me a while to get to physical therapy for it for a lot of reasons that aren’t important, but mostly relate to my being stubborn and still thinking I’m invincible with Wolverine-like healing powers. So, long story short, I’ve been in PT for about 5 weeks.

Yesterday, my physical therapist asked me if my shoulder was getting better. I of course said, “no, not really. Well, maybe a little”.

Then she did the measurements of my range of motion. And in fact, my shoulder is a lot better. It still has a long way to go, but it is much improved. And I hadn’t noticed.

I hadn’t noticed because I use it every day. I don’t give it a lot of thought. It’s just a part of my existence. The same way you never noticed getting taller until you saw that relative you only see twice a year, and they couldn’t stop exclaiming how much taller you had gotten. You look at yourself in the mirror the same every day, pull on your pants the same way every day, so those microns and millimeters never had much impact on your perception. But that doesn’t change the fact that you had gotten significantly taller.

Weight loss is the same way. I could go on…

The point is, change happens slowly. You don’t notice that you are becoming a better coder, a better tester, a better coach, a better team, whatever. You don’t notice the improvements that have taken place. And so it’s easy to say, “this %$#@ place, it’s no better today than it was a year ago”. And in fact, you’d be completely wrong. It is better (and probably worse in other ways, such is life). You just never took the time to notice. There is no crazy aunt that shows up one day and says “wow, look how you’ve grown”.

So, take a few minutes. Maybe once a sprint, once a month, once a quarter. Whatever timeframe works for you. And reflect on how you’ve improved. How your team has improved. Do it with your team – you’ll probably find it to be a fun positive feedback loop. Enjoy the successes.