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’
Posts Tagged 'software engineering'
Tags: development, Electronics Engineering, Engineering, software engineering, software testing
Tags: development, programming, Software, software engineering
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.
Tags: development, software engineering
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.
Tags: programming, software engineering, visual debugger
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.
Tags: Requirements, software engineering
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.