Category: "general"

The Purpose of a Unit Test

general, reliability, CodeProject, maintainability 2 feedbacks »

I would like to clarify the purpose and intention of a unit test for every role even tangentially related to the development of software. I have observed a steady upward trend, over the last 15 years, for the importance and value of automating the software validation process. I think this is fantastic! What I am troubled by is the large amount of misinformation that exists in the attempts to describe how to unit test. I specifically address and clarify the concept of unit testing in this entry.

Full story »

From Good to Great

general, CodeProject Send feedback »

Having good engineers on your team can make the difference between a projects success or failure. Good engineers are able to jump in and solve problems, design the solution, and implement the code to make it all work. They may be on the team from the start, or brought in at the end to help get the project on track and ready to ship. The bottom line is they get things done. Every company desires for their development team to consist of good engineers or better, however, the good engineers are not easy to find. To maximize your value, what you should be looking for are the great engineers. What's the distinction?

  • Good Engineers write solid code and get the job done.
  • Great Engineers make it possible for the other engineers to become Good Engineers.

Full story »

Software Maintenance is a Myth

general, CodeProject, C++ Send feedback »

Code maintenance is generally viewed as a separate task in the development lifecycle. The hard work of designing and implementing the product has been performed, and although software test did their best to get in the way and kept finding issues the program, the product shipped. Now comes the maintenance. Lets move our best engineers to the next product, and the junior engineers will maintain this product, indefinitely. While I am being a bit facetious and completely sarcastic, this pattern seems to occur frequently in our industry. This attitude towards software code maintenance actually sets up the product for failure down the road.

Full story »

View C++ as a Federation of Languages

general, communication, CodeProject, C++ Send feedback »

My favorite C++ books are from Scott Meyers, Effective C++ series. The first item in Effective C++, 3rd Edition is titled View C++ as a federation of languages. I took note of this suggestion the first, and each successive time I read through this book. I thought of this as a fresh way to view the breadth of diverse features and ways to apply the C++ language. However, the more I explore, learn, write and teach about the language, the more I believe this is such a profound piece of advice to help developers write the most maintainable code possible.

Full story »

Abstraction Layers of the Human Body

general, adaptability, CodeProject Send feedback »

I think that almost no one would disagree that the human body is a very complex structure. Most of the complexity is hidden from our view. I would like to make a literal comparison between the human body and abstraction layers, as though the body was defined in software. I want to hopefully connect the dots for many to help convince you of the ultimate importance of a well defined and protected interface.

At the outer-most level there is the body itself where a small sample of its interfaces are capable of:

  • Sensory input is given in the form of the 5 senses.
  • Communiucation can be expressed with a variety of means:
    • Speech is expressed with the mouth
    • Signals expressed with sign-language
    • Emotions conveyed with body language
    • Pheremones and other more subtle message transports
  • Energy and medications are administered through a finite number of orifices.
  • Waste and excrement are ejected through well defined interfaces. (When things leave the body from unexpected orifices, this should be concerning.)
  • When the body is sick, it expresses symptoms in many ways. Some of them are only internally detected, others are clearly visible or audible.

Full story »

Test Driven Development

general, reliability, CodeProject Send feedback »

Test Driven Development (TDD) can be a very effective method to develop reliable and maintainable software. However, I have witnessed instances where the development process and results were from ideal because the tenets of TDD were not fully understood. I will provide a brief overview of TDD, which will include a description of the concepts, development process and potential benefits associated with TDD.

Full story »

Code Rot

general, CodeProject Send feedback »

What is code rot

A.K.A software rot, code decay, code entropy; there are many similar names. 

Code rot: A term used to describe the quality of source code as it changes over time and migrates further away from the orignal design. This may continue until the code is no longer viable. A passive use of the term code rot describes the source code for an aging system that require dependencies or tools that are no longer available. Eventually the hardware fails and there is no way to update or port the software to newer tools.  

This entry will focus on the former variant rather than the latter because it describes active code rot. Each and every change to software can introduce decay. Please recognize that rot, decay, and entropy, these are all just another word for risk, which is the potential for a problem to occur. 

Full story »


general Send feedback »

This is a journal for those who feel they have been damned to live in a code base that has no hope. However, there is hope. Hope comes in the form of understanding how entropy enters the source code you work in and using discipline, experience, tools and many other resources to keep the chaos in check. Even software systems that have the most well designed plans, and solid implementations can devolve into a ball of mud as the system is maintained.

Software maintenance is definitely a misnomer. Once the system has been tested and delivered, any further changes are simply another round of design and development. Unfortunately, Software maintenance is typically left to junior level developers in order to free the senior level engineers to move on and make the next shiny object. When in fact, I believe the re-engineering of a software system should be led by the most skilled engineers of the organization.

In my experience, a set of newly developed code tends to hold its original design integrity for about 12-18 months after the original phase of development has completed. After this amount of time, the original vision seems to get lost, schedules become king, the original developers have moved on etc. These are some of the many reason that code seems to rot. There really is no single force to blame, just as there is no single fix to prevent this from occurring either.

I had been a software engineer for more than a decade before I realized that much of the code that I have written was really horrible, at least from a maintenance, or re-engineering point-of-view. Up to that point in my career, I usually found myself working at a new company every two years. This seems to be a common trend in this industry given the high-demand for good talent, volatility of technology startups and the enormous amount of opportunity that exists. The only problem is this never put me in the position to live in the filth that I had just helped create. I actually have found that once I was put in this position, it became a great opportunity for learning and honing my skills for this craft.

I will continue to document various experiences, tips, tricks, practices, tools, mantras and whatever else I have found useful along the way to become a better engineer. Now, with very little extra effort, I write each programming statement as if I will be continuing to re-engineer this same set of source for many years to come. Please continue to visit and learn, as well as share your experiences and practices that you have discovered for software maintenance. I also welcome any questions.

Best Regards,

Paul M. Watt

Contact / Help. ©2017 by Paul Watt; Charon adapted from work by daroz. blog software / web hosting / monetize.
Design & icons by N.Design Studio. Skin by Tender Feelings / EvoFactory.