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.

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.

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.

C++, CUDA, Python, and Really Big Cameras

I can’t believe this blog is still here. Amazing. I figured WordPress would close it down by now.

A lot has happened since the last entry. My book was released by O’Reilly (and it’s been doing OK), I came down with a severe case of food poisoning (and ended up in the ICU), and some months later had triple-bypass open-heart surgery (and another stay at the Hotel ICU). Fun times.

Here’s a link to the book, if you’re interested (shameless self-promotion):

http://shop.oreilly.com/product/9780596809577.do

and of course it’s also available on Amazon.

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.

Software Musings

A collection of musings on software design and development:

Testing without requirements is just a pointless activity of exercising the compiler and demonstrating the programming language.

Software that lacks documentation also lacks a clear reason for its existence–it is easier to throw away undocumented software than it is to discard something that someone took the time and effort to document.

A badly written requirement is worse than having no requirement at all. Without a requirement there’s at least a 50-50 chance of getting it right.

Programmers are not software engineers.

A debugger can be a useful tool or a crippling crutch–it’s up to the user to decide which it will be.

Programming on-the-fly with a debugger is just hacking.

Large amounts of buggy data and/or control coupling in a program usually indicates that it was created with little or no up-front design.

It is an undisputed fact that fixing a design defect after software is released will cost vastly more than fixing the defect at the requirements or design stage.

Unit testing is not the last word for software verification, it is only one small part of the whole testing scheme.

Functional testing demonstrates the acceptability of a software product, but without functional requirements there is no way to design effective tests.

There is no “best” language, and there is no “best” editor. It’s all a matter of using the most appropriate tools for the job, and then mastering the tools to be used.

Creating unreadable software is about the same as spitting in the face of the next person who has to try and decipher it.

Just as good art demonstrates skill and thoughtfulness on the part of the artist, so too does well written and readable code demonstrate the skill and professionalism of its author.

Some Thoughts On Software Testing and Software Test Engineering

Software testing is an artform, and, make no mistake about it, a good software test engineer is an artist.

Software testing often gets a bad rap as being “dull”, “boring” or something that the goofy wonk down the hall does, but that the hotshot developers don’t bother themselves with. I used to view testing as an evil necessity as well, until I discovered how challenging it could be.

Building Better Device Interfaces

I recently encountered an interesting example how not to implement a control interface for an external device. The devices in question here are two laser products from the same company that do essentially the same thing. The problem is that the software for each of the controller units seems to have been developed in sealed rooms with little or no cross-communication between them. I’m not going to name any names, mainly because other than the command set silliness these are good products, but I’ve suffered enough at the hands of some unknown yahoo (or group of yahoos) that I felt compelled to write up a quick “lessons learned”. I will refer to these two products as controller A and controller B.

Some Thoughts on Writing Readable Python Code

The Python document “Style Guide for Python Code“, also known as PEP-8, starts off by stating that: “One of Guido‘s key insights is that code is read much more often than it is written.” While I won’t dispute that, I do have some thoughts on reading code in general. I’m a big fan of re-use, and I don’t like to spend any more time reading code than I absolutely have to. I want to get on with it and get the project done. But not everything comes with a set of nicely written man pages or a detailed reference manual, so I do find that I have to actually read the code every now and again. And while I may grumble about the time I spend doing it (and thinking about all the other people doing the same thing because someone couldn’t be bothered to write any documentation), what really makes me cranky is when the code is hard to read to begin with.

The “Software is Simple” Syndrome

In looking back over the years, it seems that I have worked in either the rigorous environments of hard real-time mission critical software, or I’ve worked in scientific research environments. Which strikes me as odd, since the two realms are, in many ways, polar opposites when it comes to how software is designed, implemented and tested. I would have to say that while I like the formalisms of the embedded real-time work, I also enjoy the intellectual challenges of scientific programming. But there’s a price to be paid for that, and I want to share with you my thoughts on that score.