Posts Tagged 'Software'



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.

OS/2 – A Good Idea That Could Have Been Great

I loved OS/2, I really did. OS/2 version 1.3 was, in my opinion, the best small multi-threaded OS ever created. Period. Gorden Letwin and his team did an amazing job with it. Those who are interested might want to scrounge up a copy of “Inside OS/2” by Letwin and give it a read.

IBM’s versions, from 2.0 onwards, extended the OS with better GUI support, real multi-platform interoperability and backwards compatibility. I was an OS/2 developer from 1.0 through 2.1, and a participant in IBM’s OS/2 developer’s program (I even purchased several big PS/2 machines, very nice for their day, and gave presentations about it). I was also heartbroken when IBM pulled the plug on OS/2 and effectively doomed it to obscurity. But, I’ve since moved on to Linux and FreeBSD, and I haven’t looked back. At least not very often.

Continue reading ‘OS/2 – A Good Idea That Could Have Been Great’

Why Building Stuff is Hard

If you work in a technology related field you may have encountered the situation where someone, be it a well-meaning relative or a new acquaintance at a party, will hear about what you do for a living and then say “Hey, I have this great idea! Why don’t I tell you about it and you can make it, then we can get rich!”.  Or, they might say (as my father was want to do) “You’re smart, why aren’t you working for yourself building clever things instead of working for someone else?”

The person saying this may even be well-educated and not someone who seemed to escape from a mental hospital (my father was a medical doctor). They might even have a really good idea. Sadly, however, what they don’t have is a clue. This is one of the main reasons I go out of my way to avoid telling people what I do for a living and the things I’ve worked on. I get weary of the typical stereotypes, so I just mumble something about working with computers and then try to wander off before they can press the issue.

But it isn’t just the clueless folks who think that building stuff is easy. People who should know better (in my opinion, anyway) also fall into the trap of thinking that things should be easy. The problem is that there is a very, very big step between putting some sketches and notes on a piece of paper, and actually making something that works. The notes and sketches are the easy part, and BS costs nothing.

Continue reading ‘Why Building Stuff is Hard’

wxPython and wxWidgets Documentation Gripes

wxPython is an interesting package, built on the underlying wxWidgets C++ GUI library. It’s full-featured and relatively platform independent. However, it suffers from a malady common to a lot of open source software.

The documentation sucks. Period.

Continue reading ‘wxPython and wxWidgets Documentation Gripes’

Bargain Hunting – Buying Used Equipment

I’m one of those people who has a collection of old (OK, some are ancient) computers, test equipment and what-not floating around. Over the years I’ve collected, and discarded, literally truckloads of stuff, including a complete DEC MicroVAX system, a DEC PDP-11/34, an HP-3000, and a slew of 9-track tape drives, line printers, oscilloscopes, logic analyzers, old PCs of various flavors, and boxes of loose parts. And that’s just the stuff I can remember without thinking too hard about it. I still have too much junk, but I’ve been applying the “If it doesn’t light up and work when I plug it in, then out it goes” rule as much as possible (sometimes it’s painful, though).

Continue reading ‘Bargain Hunting – Buying Used Equipment’

Stripping Strings – A Python Utility

I do a lot of work with various external devices that communicate via a command-response protocol using ASCII strings.  Unfortunately some of these gadgets don’t have symmetrical responses, and some even include characters that, while they are valid ASCII values, don’t really make any sense (unless it was someone just trying to be clever without thinking things through completely).

Continue reading ‘Stripping Strings – A Python Utility’

The Grand Debut of “Software Engineering”

I have a treasured book containing the proceedings of a NATO conference held in 1968 in Garmisch, Germany. It was the first time that the term “Software Engineering” had been used in such a bold fashion. It’s a first edition copy.

Recently I came across a web site that provides both the 1968 and 1969 conference proceedings. It can be found here:
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/

When I read the 1968 proceedings I was flabbergasted by the topics discussed. Most of the book could have been written a few years ago. They had indentified the same issues then that still plague the software development community today: lack of documentation, lack of testing, lack of processes. Amazing.

So, go take a look for yourself. I paid a lot of money for my book (and it was worth every penny). You can get yours for free.

And prepare to be amazed at how little has really changed over 40 years.