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’
Archive for the 'Processes and Procedures' Category
Tags: development, Electronics Engineering, Engineering, software engineering, software testing
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.
Tags: C++, CUDA, Gigapixel, programming, Python
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):
and of course it’s also available on Amazon.
Tags: programming, software engineering, software testing
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.
Tags: programming, Software, software engineering
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.