Frustrating Development Tools

I have a complaint (well, to be honest, I have a lot, but I don’t trot them out all at the same time): Why do hardware and development tools vendors insist on using things like Windows .net? It annoys me to no end to have to resort to reading through KB articles from Microsoft just to get something as straightforward as a compiler up and running. It annoys me even more when I can’t get the software running even after jumping through hoops and hopping up and down on one foot while patting the top of my head. Does it really have to be this way?

I can understand why someone would want to use Windows for their development tools. It seems that many (or most) of the engineers and technicians in the EE and embedded systems communities either won’t, or can’t, deal with anything other than Windows, so it makes sense to provide something that they can understand and use. What I don’t understand is why someone didn’t bother to take a moment to work out the consequences of using something like .net when the tools were built. This, I believe is the real problem. Marketing states that the software products need to be “sexy” or “modern” with lots of bells and whistles, regardless of how it is built. Unfortunately, marketing people are the least qualified to make technical decisions about much of anything. They sell stuff, they don’t design it or have to deal with it when it doesn’t work like they think it should. The software developers, whom may, or may not, be experienced enough to understand the consequences of their actions, toss together something with a cool looking GUI that works fine on their development system, but then they apparently don’t do a sufficient amount of cross-platform operational testing. Marketing is happy, the SW people get a pat on the back, and the end users are left to struggle with what is, effectively, poorly tested beta software.

So we end up with tools and SDKs that won’t install correctly across the stated range of platforms without some additional fiddling. Microsoft platforms can vary significantly below the pretty desktop GUI, depending on how they are configured and what extensions are in use. If you happen to have the latest version of Windows, a fast Internet connection, and a little patience, you have a chance of getting things to work. If, on the other hand, you have a legacy development system that is configuration controlled (i.e. the base OS and its components stay the same for testing and verification purposes), then you may well be screwed. Unlike other operating systems, Windows does not allow core add-on functionality to be installed without fiddling with the registry, installing system level DLLs, and doing a reboot. If the version of Windows you need to use is no longer supported, intentionally does not have some specific extension, or is in some way non-standard, then you will most likely have to resort to wasting a few hours reading through knowledge-base articles and doing the install-reboot-remove-reinstall cycle multiple times. And there’s no guarantee that you will succeed, although you may end up breaking your configuration and possibly your development system.

So, no, it doesn’t have to be like this. Get the marketing department out of the engineering design process, build development tools that can work from the command prompt as easily as with a GUI, don’t use Windows extensions like .net, and try to future-proof your work by thinking in terms of cross-platform operability. Don’t lock end users into one version of Windows–not everyone is willing to go out and buy the latest version of Windows and a PC to run just to be able to use your tools. They can always pick a different part with similar capabilities that doesn’t chain them to your particular approach.

And, trust me, the engineers and developers like myself who use multiple platforms and do work that requires stringent requirements traceability and configuration management will look elsewhere. The success of the ARM Cortex M series and Atmel’s AVR MCUs are proof of that. Tell that to marketing the next time they whine about needing something that will “establish their image in the market” or “looks better than the competition’s offering”. Personally, I don’t care that much how it looks–I’m not interesting in playing video games with my tools while I’m trying to design something. I’m only interested in results, and tools that fight me and force me to wrestle with it or the OS will be put aside in favor of something that I can use without wasting my time.


0 Responses to “Frustrating Development Tools”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Follow Crankycode on

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: