Monthly Archives: March 2014
Quad Core Arm Computers
I have always been fascinated with small computers. I have a Chumby, some ZipIt Z2s and I had a plug computer that recently died. I’ve been considering replacing the plug computer with a small Linux arm computer. My prerequisites are: Wired Ethernet, Silent, Low Power, ability to host source control and ssh. Video output would be nice. I have been hesitant to spend too much, because I have previously bought them and barely used them. So far I have seen two contenders, NanoPC-T1 and the ODROID-U3.
I am a bit of a tech hoarder, so I have to liquidate some previous older computers before I buy anything new.
I ran into a very funny programmer related web comic called CommitStrip. Some of the jokes hit very close to home, much like the above strip. I work incredibly hard to make my code clear, concise and readable by other people, but there is still a level of unfamiliarity that makes learning another person’s code difficult.
My longtime friend Pavan Tumati has a great blog, The P-Tumati Distribution, dealing with hardware and software. He has an eclectic range of technical skills and posts. He is always pushing me to learn something new.
Coder Radio Podcast
I consider myself a generalist when it comes to software development, but I know I have gaps in my knowledge base. If you are the sole programmer or surrounded by people who do not show a desire to learn new things, it is very easy to become obsolete and irrelevant. As hardware keeps progressing forward, software engineers keep adding additional abstraction layers to increase productivity. Knowing these abstraction layers and other technologies is difficult even if you try to learn something new every day. To balance out my finance and science heavy podcasts, I have added Coder Radio to my list. I have finished six episodes and so far the content is great for software engineers. I like it because the host works in an area foreign to my daily development.
I typically listen to podcasts when commuting to and from work and doing chores on the weekend. I have tried to balance the content generation with the consumption, unfortunately there is only so many hours in a week.
Eliminate Potential Bugs
If we really want to achieve software with an extremely low defect rate, it is not enough to react to software bugs and fix them after they have been introduced. One of the main principles of my style of software development is that we have to go on the offensive and eliminate or reduce the possibility of their creation.
Now this sounds like a good principle, but it is one of the hardest to achieve. It is hard to achieve because it fights the human desire to get quick results even if the results are not completely correct. We want to show something that works in most cases, but bugs often occur in the least used cases. Also if we tried to avoid every kind of potential bug out there we would probably never finish our task. So we want to find all the situations where avoiding an issue is more cost effective than dealing with the bugs that are caused by them. If you have ever spent a week, day or even an hour on a bug, you will realize how much extra code you could write to avoid the issue and still come out ahead.
Basically go through the kind of bugs that occur and ask yourself “How can I reduce creating this kind of bug again? Is it cost effective to do so?” After a while you will realize that additional code will often get you to a low defect rate sooner.
A probabilistic view of software development
For the majority of my life I have focused on becoming a better software engineer . I hope to share what I have learned to help other software engineers. Most of my career has been doing biomedical devices where software correctness is critical. By “correct” I mean bug free.
Unfortunately software development, even in the biomedical industry, has not achieved the maturity where we routinely prove our software correct. The current reality is that 99.99% bug free software without proving correctness is significantly cheaper than 100% bug free software by proving correctness.
So if we relax our bug free requirement how can we increase our chances of being correct? First we need to identify where bugs come from. It not like bugs are just random bit flips in binaries. A bug is is almost always due to an error in line of source code.
Now anybody who has programmed before knows the plethora of possible mistakes that can be made in a single line of code. You can use the wrong variable, misplace a comma, forget an prerequisite, forget to check an error state, off by one, memory leaks, etc. There are a nearly infinite ways of writing a line of code wrong. But after a while you will notice that there is not a equal distribution of mistakes made. You will notice that there certain kinds of mistakes in a line of source code that keep re-occurring.
Furthermore some kinds of bugs are more difficult to diagnose than other bugs. If we make the realization, that because we are human, we can not completely avoid mistakes in our software. I believe we can at least try to shift the kinds of bugs we have to ones we can more easily diagnose and fix.
So hopefully I will show you how to increase your productivity as a software engineer through knowing the trade offs you make in writing each line of code. A lot of these are considered best practices, but hopefully this probabilistic view of software development will help explain why they are good practices.
Recent Comments