Getting Dumber ?

I needed to take my car for a service today (I had some strange knocking noises coming from the engine), while the mechanic was delving around under the hood and making appropriate mechanic sounds (the odd ‘hmm’ here and there – which is always a little disconcerting, do more “hmm’s” translate to more money to fix the vehicle?) I was thinking about the work involved in working on todays cars – just looking into the engine compartment there’s nothing obvious that a typical user would be able to tamper with, beyond topping up the washer fluid bottle. Engines, and engine management systems have become so complex that for the most part maintenance is out of the hands of the general owne. When cars were first introduced every owner needed to know how to fix the vehicle by the side of the road – this is certainly not the case today.

So what about developers, do we see a similar trend here ? – I would suggest that we do…

Remember writing graphics programs for MS-DOS ? You needed to code your application to the specification of the video card you were using, whereas today on Windows (XP, XP Embedded, CE) this is totally abstracted away from you – when writing an application that uses graphics you can query the size the screen, the size of your client area, the supported color depth, and don’t even need to code your own line drawing routines – you just get a device context or graphics surface and rock on…

Which leads nicely onto application development in general, I come from an assembler, C/C++, MFC, C# background, when writing applications for the first versions of Windows the application development tools were somewhat crude – the tools didn’t contain any Wizards to create the skeleton of the application (in fact, I would just clone a copy of the Windows SDK sample “Hello World” and then modify from there), in fact, everything needed to be done ‘by hand’. If we spin forward a few years to the introduction of Visual Basic now everyone can be a programmer, right ? (see my first VB application post) – Writing Visual Basic applications is closer to painting by numbers than actually writing code, let’s create a new instance of a COM object, simple, not a sign of CoInitialize( ), CreateInstance( ), QueryInterface( ) – a couple of lines of code and you’re done – in fact you don’t even need to know anything about COM to start using COM components – Now spin forward another few years to Visual Studio .NET, as a C# or Visual Basic developer calling a SOAP service exposed across the other side of the big white fluffy cloud known as the internet is as simple writing two lines of code, now try doing the same thing in ‘C’.

‘C’ what I mean  – Application development is getting easier, the underlying development frameworks and development tools are doing the heavy lifting for you – heck, you don’t even need to free up objects that you create in managed applications, these are cleaned up for you by the framework.

So, what about Embedded Developers ? – Are you still grubbing around in the guts of an operating system when building your device, or are you spending your time configuring your embedded device and adding value ? sure, writing drivers and building BSP’s is the tough bit, but once you have a running BSP it’s simple from there on in, isn’t it ? – In fact, with Windows XP Embedded you don’t need a BSP since the underlying hardware is going to be built to the PC specification, so it’s just a case of figuring out which drivers are needed and then you’re all set (heck, there’s even a tool for that!) and for Windows CE there are a number of BSP’s that ship with the operating system development tools, and even more 3rd party BSP’s available (of course you may need to create a BSP and drivers if you’re building totally custom hardware for Windows CE).

So, finally onto the question – is embedded development heading the same way as desktop application development ? – operating system development tools are getting smarter, developers don’t need to know so much about the underlying hardware (especially when using Windows XP Embedded), the tools are doing more of the heavy lifting leaving developers free to concentrate on their added value.

Your thoughts ?

– Mike


Comments (10)

  1. everquest says:

    For me, as a developer this tools make my life a lot more confortable.

    The day when .NET application run out of the box on any embedded platform my dreams come true.

  2. David Smith says:

    I absolutely agree with the point of your post, but I think the title of your post is misleading.

    In almost all aspects of software development I’ve encountered, developers are not "getting dumber", as much as they’re "shifting focus".

    I think it’s important to take our focus shift into perspective. I think it’s very positive that developers are using more of their time designing better systems than dealing with symantics.

  3. Steven Fowler says:

    Software development will continue to be an engineering discipline because systems requirements are as increasing complex as the technologies used to build them.

    Case in point: My last client employed BizTalk 2004 because they were told that they could hire a team of analyses (cheaper than engineers) to assemble EAI solutions with the aid of one Jr. Developer to author a few functoids. Bla ha ha ha ha ha!

    – Steven Fowler

  4. Uwe Keim says:

    Everyone (including myself) seems to repeat the words like "…shifting focus…" that come from the vendors of more high-level development environments/platforms like Java or .NET.

    I think it is a great benefit that I can ignore the details and focus on the algorithm.

    But if I think about the future, I fear that we (the developers) are slightly loosing bit for bit of our knowledge to the "big framework author" (like e.g. Microsoft) and some day we suddenly see, that we must take whatever the "big framework author" gives us, because we moved step-by-step into a deep dependency on the "big framework author".

  5. The bulk of our embedded applications run on 8-bit micros – 64K memory space max. No Linux, Windows CE, RTOS – just state machines coded in C or Assembler when necessary for maximum speed. Approximately 90% of all embedded applications run on 8 or 16 bit micros and are constructed in this fashion.

  6. Anon says:

    Having recently come out of school in Computer Engineering and now working with Computer Scientists and techs, I can say that there are both pros and cons to this. By not having to worry about the details we can definately spend more time on design and architecture…until we hit a snag. Then no one really knows what to do.

    My co-workers haven’t learned the underlying principles and the "nuts and bolts" that make it all work. It can be very frustrating trying to explain solutions and/or the root problems when my fellow "Software Engineers" don’t have a clue what I am talking about. One of them actually gave me a blank look when I asked him to genereate an assembly listing so I could see what he was doing…

    Working in embedded systems requires a fairly good knowledge of how things work so as to optimize your code as you need to. While the new dev tools are getting better, they really cannot replace a detailed knowledge of what is going on. Similar to trying to repair an automobile these days…

Skip to main content