Don’t Let Your Code Marry An Axe Murderer

Tuesday, January 12, 2010

272/365 It’s a lesson I learned from the school of hard knocks: be careful about the shady characters you let into your software.

There are lots of software frameworks, components, and tools in the world – and they all want you to think you can live with them happily ever after. They seduce you with the promise of productivity, then hack you to death once they’ve gained your trust.

Here are a few questions I’ve learned to ask when trying to spot next year’s problems:

1. How easy is it to deploy?

I’ve been burned by software that is difficult to move from one environment to the next. Some products, particularly server products, assume you never need to move software into different environments (like development, test, productions). Avoid anything you can’t automate!

Software should be as easy to deploy as possible, otherwise it doesn’t get deployed often enough.

2. Will it work in source control?

Some tools and designers generate files that don’t work well under source control. If you can’t diff and merge you lose a tremendous amount of flexibility when it comes time to branch, patch, and support concurrent development. Database tools are historically notorious for having problems in this area because they tend to design for DBAs instead of developers.

It is, however, perfectly reasonable to check in binary dependencies.

3. Is it needy?

Speaking of dependencies – they are a touchy subject. You can’t invoke the “not invented here” rule in every decision without writing your own compiler. At the same time, every dependency you introduce to a product is a calculated risk. How many dependencies does this new thing have? Will you ever delay shipping because you are waiting for a new version of a dependency? Will you ever delay shipping because you are waiting for a new version of a dependency’s dependency? How many things will break when the next version arrives? Are you willing to run beta code, or code from the trunk? The answer is different for every application and business.

In the end you need to make a decision from the gut, which means research into the history and pedigree of a dependency might be required.

4. When will it be obsolete?

If you implement the solution to a problem in a mainstream programming language like C#, you can be reasonably sure it will still work and compile in 5 -10 years, even with new versions of the compiler. But, if you implement the same solution with Data Transformation Services (wait, that’s obsolete), or Notification Services (wait, that disappeared), or SQL Distributed Management Objects (oops, it’s only a matter of time) - then you got some rewritin’ to do!

Remember – nothing lasts forever … unless you have all the source code.


Comments
gravatar Tom Janssens Tuesday, January 12, 2010
FYI, The coding horror archive links do not seem to work ??
gravatar Tom Janssens Tuesday, January 12, 2010
Aha, the hosting company for both haacked & codinghorror has some problems again ?
gravatar scott Tuesday, January 12, 2010
@Tom: The blogs seem to be working again.
gravatar Kalpesh Tuesday, January 12, 2010
Scott,

What do you think of .net in terms of ease of deployment & configuration?

I think as we progress, things get more complicated.
gravatar Matt Briggs Tuesday, January 12, 2010
Above and beyond just disappearing, you should try to see if the products future vision aligns with yours. I am working at a place that is using Community Server, which has been focusing on things like sharepoint integration and intranet CMS features, which happen to be completely useless for us.

Another thing to keep in mind is how "black-boxy" it is. We are also using CommerceServer, and debugging issues can be a real pain. You trace code, and then you hit the <CommerceServer Magic Goes Here> section, and then data is saved into a fairly obfuscated database schema. It is hard to know if it is a commerce server bug (which we have run into a few times), our bug, or a configuration issue.
gravatar scott Tuesday, January 12, 2010
@Kalpesh: Overall I think we're still ok.

The framework is bigger (something the client profiles are meant to help with, but at the cost of more complexity), which I admit does pose a problem for some locations, but it hasn't been an issue for me.

I would agree that configuration is out of control. Witness the reams of XML needed for WCF and the total ineffectiveness of ServiceReferences.clientconfig in Silverlight.
gravatar scott Tuesday, January 12, 2010
@Matt - Those are both very good points, thanks.
gravatar Michael K. Campbell Tuesday, January 12, 2010
Database tools aren't problematic when it comes to source control because they target DBAs. Rather, it's because they target databases.

If I've got a C# class with 3,000 lines of code, that's very easy to 'difference' and vector via source control.

If I've got a table with 13M rows and need to remove or MODIFY one of the columns in that row, there's no good way to put that into source control. I can keep the table definition for what that table will be like AFTER the change. And I can even keep the script I use to tweak my table for new functionality. Neither of those will let me go back in time to what the DB was like BEFORE I made the change. Likewise, if the DB is 60GB in size, then keeping a backup isn't feasible either.

In fact, if the DB is 10MB, keeping a backup isn't feasible - as any data in that DB is likely to CHANGE over time - so having the ability to 'rollback' really becomes meaningless.

Same thing goes for diff/merge... it just isn't feasible.

Great post though.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!