Well, okay, maybe it’s not all opinion. There must be some way to tell a good technology from a bad one (besides looking back after five years of development and saying, “Wow, we really shouldn’t have decided to base our product off of Microsoft Bob.”)

When I’m evaluating a technology for inclusion in one of my projects, I look particularly at the technology’s survival potential, interoperability, and attention to quality.

By “survival potential” I mean “how long is this software going to continue to be maintained?” If you get stuck with libraries or some dependency that becomes obsolete, you’re really in for some trouble. You can get some idea of the survival potential of the software by seeing how often they’ve released recently. Also, how responsive are they to bug reports? Do they have a mailing list that’s very active with users and developers? Are there lots of people online talking about this technology? If a technology has a lot of momentum now, you can be fairly sure that it’s not going to die any time soon.

By “interoperability” I mean, “Does this system use some standard that would allow us to switch to a different system if we want, in the future?” For example, some database systems support standard SQL very well. Some other ones aren’t as good about that–they have strange behaviors that don’t agree with the standard, or they just don’t support it at all. Using a database with standard-SQL support would allow you to switch to any other standard-SQL database in the future, whereas using a less-standard database would lock you in.

The final one, “attention to quality,” is more of a subjective measurement, but the idea is to see if the product is getting better in its recent releases. If it’s open-source, check if they’re refactoring and cleaning up the code base. Is it becoming easier to use or more complex? Do the people who maintain the technology actually care about the quality of their product, or are they just code monkeys working for the pay? Are there are a lot of serious security vulnerabilities in the software that have been published lately?

Lock-in is a worse problem when you’re using proprietary software than when your dependencies are open-source. Proprietary vendors can just stop supporting something (or go out of business), whereas in the open-source world anybody is free to pick up a codebase and maintain it if the original maintainers drop it. Granted, open-source projects are just as likely to fall out of existence as proprietary projects are, but at least there’s the hope (particularly if the project was very popular) that somebody will come around to maintain it again, with open-source.

Proprietary vendors also have a monetary incentive to lock you into their technologies–even their free technologies. Once you start using their free technologies, they can sell you services and products related to them. Open-source vendors usually lack that monetary incentive, and so are more likely to be “friendly” when you want to switch away from them. This isn’t always true (some proprietary vendors beat the pants off of open-source vendors in terms of interoperability, and some open-source products will still lock you in), but it’s enough the case that I automatically think “let’s use open-source” when I’m looking for interoperability.

There are other aspects to look at when you’re choosing a technology, and some of it really is opinion. Some people like the way Ruby looks better than the way Python looks. That’s a valid reason to choose a technology sometimes–if you just like some technology more than another one, and everything else seems equal according to the criteria above, go with the one that makes you happy. After all, you’re the one who’s going to be using it–your opinion matters! All I’ve tried to do here is give some universal guidelines that can be used to weed out the definitely bad choices, and the rest is up to your personal research, needs, and desires.

-Max

Comments: 4

Code Simplicity is brought to you by Max Kanat-Alexander and BugzillaSource.

“We started working on this project five years ago, and the technology we were using/making was modern then, but it’s obsolete now. Things keep getting more and more complex with this obsolete technology, so it keeps getting less and less likely that we’ll ever finish the project. But if we re-write, we could be here for another five years!”

Another popular one is: “We can’t develop fast enough to keep up with modern user needs.” Or, “While we were developing, Google wrote a product better than ours much faster than us.”

When I hear things like that, the first thing I ask myself is “How did that happen? Why did it take so long for them to finish their product that they ran into that problem?”

The answer lies in complexity. The more complex a task is, the harder it is to complete it. So you start out with something simple that can be completed in one month. Then you add complexity, and the task will take three months. Then you take each piece of that and make it more complex, and the task will take nine months.

Complexity builds on complexity–it’s not just a linear thing. It’s not like, “We have ten features, and so adding one more will only add 10% more time.” No, one new feature will have to be coordinated with all ten of your existing features. So if just the feature itself takes 10 hours of coding time, there will be another hour of coding time for that feature interacting with each other feature. The more features there are, the higher the cost gets of adding a feature.

Some projects start out with such a complex set of requirements that they never get a first version out. If you’re in this situation, you should just trim features. Don’t shoot for the moon in your first release–get out something that works and make it work better over time.

There are other ways to add complexity than just adding features, too. The most common other ways are:

• Expanding the purpose of the software. Generally, just don’t ever do that. Your marketing droids might be drooling over the idea of “making a single piece of software that does your taxes and cooks dinner”, but you should be screaming as loud as you can whenever any suggestion like that comes near your desk. Stick to your purpose–your software just has to do what it does well, and you will succeed, if that purpose is something people need.
• Adding programmers. Yes, that’s right–adding more people to the team adds complexity, it does not make things simpler. Remember The Mythical Man Month? What he says in there is true because of the complexity equation I explained higher up in this article–if you have ten programmers, adding an eleventh means spending time to groove in that one programmer, plus the time to groove in the existing ten programmers to the new guy, plus the time spent by the new guy interacting with the existing ten programmers.
• Change things: Any time you change something, you’re adding complexity. Whether it’s a requirement, a design, or just a piece of code, you’re introducing the possibility of bugs, the time required to implement the change, the time required to validate that the new change works with all the other pieces of the software, the time required to decide upon the change, and the time required to track the change, and the time required to test the change. Each change builds on the last in terms of all this complexity, so the more you change, the more and more time each new change is going to take. It’s still important to make certain changes, but you should be making informed decisions about it, not just changing everything on a whim.
• Lock-In to bad technologies. This is where you make a bad decision about your backend or libraries and then are stuck with it for a long time because you’re so dependent on it. Obviously “bad technology” is very subjective, but sometimes there are obvious good choices and obvious bad ones. For example, if you need an embedded scripting language, Lua is generally considered to be a good choice, and “write our own” would probably be one of the worse choices, depending on the situation. It’s definitely relative–it’s not like there’s only one good choice and all the rest are bad, but some choices might make your life easier than others.
• Poor design or no design. Basically, this just means “a failure to plan for change.” Things are going to change, and that requires design work, to maintain simplicity while the project grows. Failing to do this can introduce massive complexity very fast, because suddenly each new feature quadruples the complexity of the code instead of just adding a little bit to the complexity.
• Re-inventing the wheel. For example, if you invent your own protocol when a perfectly good one exists, you’re going to be spending a lot of time working on the protocol, when you could just be working on your software. You should basically never have any huge invented-in-house dependency, like a webserver, a protocol, or a major library, unless that is your product.

The thing about all of these is that they’re insidious. Most of them only do long-term damage–something you won’t see for a year or more. So when somebody proposes them, often they sound harmless! And even when you start implementing them, maybe they seem fine. But as time goes on–and particularly as more and more of these stack up–the complexity becomes more apparent and grows and grows and grows, until you’re another victim of that ever-so-common horror story: “The Never-Shipping Product.” (Which is nowhere near as cool as The Neverending Story, believe me.)

-Max

Comments: 1

Code Simplicity is brought to you by Max Kanat-Alexander and BugzillaSource.

Above and beyond any vague philosophical or moral considerations about this, the technical problem here is that this creates complexity.

Where once users of your API only had to call a simple function, now they have to do a version check against your application and call one of two different functions depending on the result. They might have to pass their parameters a totally different way now, doubling the complexity of their code if they keep both the old way and the new way around. If you changed a lot of functions, they might even have to re-work their whole application just to fit with the way your new API works!

If you break your API several times, their code will just get more and more and more complicated. Their only other choice is to break their compatibility with old versions of your product. That can make life extremely difficult for users and system administrators trying to keep everything in sync. You can imagine how quickly this could spiral out of control if every piece of software on your system suddenly broke its API for interacting with every other piece of software.

For you, maintaining an old API can be painful, and getting rid of it can make life so much simpler. But it’s not complexity for you that we’re talking about particularly here, it’s complexity for other programmers.

The best way to avoid this problem altogether is don’t release bad APIs. Or, even better (from the user’s perspective), create some system where you promise to always maintain the old APIs, but give access to more modern APIs in a different way. For example, you can always access old versions of the salesforce.com API merely by using a different URL to interact with the API. Every time you interact with the SalesForce API, you are in fact specifying exactly what version of the API you expect to be using. This approach is a lot easier in centralized applications (like salesforce.com) than in shipping applications (like Bugzilla), because shipping applications have to care about code size and other things. Maintaining old APIs is also very difficult if you only have a small team of developers, because that maintenance really takes a lot of time and attention.

In any case, releasing an unstable or poor API is going to either complicate your life (because you’ll then have to maintain backwards compatibility forever) or the life of your API users (because they’ll have to modify all of their applications to work with both the “good” and “bad” API versions).

If you choose to break your API and not provide backwards-compatibility, remember that some API users will never update their products to use your new API. Maybe they just don’t have the time or resources to update their code. Maybe they are using a tool that interacts with your product, but the maintainer of the tool no longer provides updates. In any case, if the cost of fixing their code is greater than the value of upgrading to new versions of your product, they could choose to remain with an old version of your product forever.

That can have a lot of unforseen consequences, too. First they keep around an old version of your product. Then they have to keep around old versions of certain system libraries so that your product keeps working. Then they can’t upgrade their OS because the old version of your product doesn’t work on the new OS. Then what do they do if some unpatched security flaw is exploited on their old OS, but they’re still tied to your old product and so can’t upgrade their OS? Or some security flaw in your old product is exploited? All of these situations are things that you have to take responsibility for when you choose to break your API.

And yet, having no API can lead to the same situation. People create crazy “hacks” to interact with your system, and then they can’t upgrade because their hacks don’t work on the new version. This is not as bad as breaking your API, because you never promised anything about the hacks. Nobody has the right to expect their hacks to keep working. But still, if management orders them to integrate with your product, those clever programmers will find any possible way to make it work, even if it sticks them with one version of your product forever.

So definitely make an API if you have the development resources to do it. But put a lot of careful thought into your API design before implementing it. Try actually using it yourself. Survey your users carefully and find out exactly how they want to use your API. Generally, do everything in your power to make the API as stable as possible before it’s ever released. It’s not a matter of spending years and years on it, it’s just a matter of taking some sensible steps to find out how the API should really work before it’s ever released.

And once it’s released, please, please, if you can help it, don’t break the API.

-Max

Comments: 5

Code Simplicity is brought to you by Max Kanat-Alexander and BugzillaSource.