Posts Tagged 'software engineering'

Maps and Plans

Every journey goes more smoothly with a map of some sort. Whether it’s a trip to Antarctica or developing firmware for a new microcontroller-based device, it helps to know where you’re going. Without a clear definition of the destination it’s tough to know when you’ve actually arrived. It is also helpful to know what it is, exactly, you expect to find when you do finally arrive. Continue reading ‘Maps and Plans’

Fear of the Unknown

Humans are strange creatures. In general we like things to be nice and predictable; the same tomorrow as today, and the same as yesterday. I don’t have any hard data to reference, but I suspect that, overall, the human race is rather conservative. We don’t like new things that challenge our current beliefs and knowledge. This is ironic, considering that we now live in a time where change is about the only reliable constant, and new things are appearing at an astounding pace. Continue reading ‘Fear of the Unknown’

Why Software Matters

Software matters because without it a computer-controlled instrument, device, or system is just a collection of plastic, metal, and silicon. It does nothing.

Without software an interferometer is just a bunch of mirrors and lenses. Without software a CCD or CMOS image sensor is just a slab of inert silicon. Without software a deep space probe is a piece of very expensive metal sculpture. Without software data collection and analysis becomes an exercise in jotting numbers in a notebook, pushing a slide rule to get approximate numerical results, and dealing with errors. Lots of errors.

Good software is not trivial, nor is it easy. It is not the simple exercises encountered in undergraduate courses, nor is it the hacked logic and unreadable gibberish generated by overcaffeinated graduate students late at night. Good software is the result of applied discipline, resulting in the creation of an abstract logical construct that is coherent, readable, elegant, and reusable. Good software is beautiful.

Continue reading ‘Why Software Matters’

Wrestling with Visual Studio

A few months ago I had a relatively large C++ source code set for a suite of applications dropped into my lap. Well, that’s OK, I don’t mind C++, but what I did mind was that it was all written using Visual Studio.

It’s been a long time since I had to work with Windows code, and now that I’ve waded through line after line of code and  wrestled with Visual Studio along the way, I’ve recalled now why I don’t like working with Windows.

Continue reading ‘Wrestling with Visual Studio’

Some more reasons why Software Engineering is so damned important

This is a slightly altered version of the summary of a report I wrote for a company that attempted to explain to them why they should have a software engineer (a real one) on their staff, and why it would help their bottom line.

Reviewing and working with most legacy software typically leads to an observation that is hard to avoid: Software engineering is arguably the most important aspect of any software implementation activity.

Continue reading ‘Some more reasons why Software Engineering is so damned important’

Visual Debuggers

A visual debugger is a like an addictive mental drug. It’s fascinating to look at, very helpful at times, and it can become a crutch. Just as with alcohol or other drugs, a little bit can be fun and help get you to where you want to be, but too much can derail you. Allow me to explain.

I do most of my development on Linux (OK, I actually do ALL of my development on Linux or something similar like Solaris or BSD–I don’t do Windows) in C, C++, or Python. When the need arises to be able to peer into the code and see what, exactly, is causing an annoying fault I use gdb or DDD (a GUI front-end for gdb) for C and C++. For Python I use tools like winpdb or Eclipse with the Python IDE plug-in.

Continue reading ‘Visual Debuggers’

Why Software Requirements Matter

Good requirements do more than just define the “what” of the thing to be produced, they also define how it will be tested and verified to insure that it really is the desired end product. But most importantly, requirements are an explicit agreement between the producer of a product and the end consumer, or customer, of that product. Without requirements things can, and often do, devolve into a mess of misunderstandings, misconceptions, shoddy workmanship and unhappy people all around. This is not necessary and it is easily avoidable if both the software developers and the customers can reach agreement on what is to be produced, document that agreement with requirements, and then manage the process of changes and revisions in a way that doesn’t fundamentally derail the project.

Continue reading ‘Why Software Requirements Matter’

It’s been a while…

In case you were wondering, well, I didn’t fall off the face of the Earth. At least not yet.

I haven’t had a chance to post anything since the middle of August because I’ve been massively busy wrapping up a big project, writing a couple of book proposals and trying to work on some technical papers. Of course that means that I’m spending a lot of time putting out little fires, chasing down issues that seem to only pop up at the last minute, and not getting a whole lot of sleep.

Anyway, I’m just about ready to post the last two parts of the PGM series, but in the meantime I would like to direct the attention of the Python folks to the tool Epydoc. If you write more than just simple utility scripts in Python, then you really should take a look at this (if you haven’t already). It may not have all the bells and whistles that Doxygen has, but it has enough to make it very useful. At work I have a cron job set up on the lab server to run Epydoc across the code base every night and put the results up where folks can access them via the internal web server.

More (much more) to come. Stay tuned, film at eleven.

Some Fundamental Software Engineering Concepts

I’m still working on Part 2 of the PGM series, so in the meantime I thought I’d toss this up here.

The following is a list of 40 questions I give to people seeking a software engineering position. I haven’t been keeping formal metrics (I should have, in retrospect), but my observations are that most recent college graduates with a BS in computer science cannot answer more than about 37% these correctly. Someone with a Master’s degree might do slightly better, but not by much (about 60% correct). A person with some years of experience as a software engineer will, of course, do pretty well (perhaps as high as 80%). Someone with years of experience as a programmer will typically do only slightly better than the person with the fresh college degree.

Continue reading ‘Some Fundamental Software Engineering Concepts’

INI Files

So-called “INI” files are ubiquitous. You can find them on Unix systems, Windows platforms, and even in the flash memory of embedded systems. I even once wrote my own INI parser for some software on a embedded diskless VME control system running WindRiver’s VxWorks. It allowed us to upload new configuration and control parameters on-the-fly in a human-readable format. Very handy.

Continue reading ‘INI Files’

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.