Habits to improve your control programming
Engineering and IT Insight: Control programming is programming, even if it uses ladder logic, sequential function charts, function block diagrams, and procedure function charts. Improve your programming in a dozen ways. Errors in control programs can harm people, damage equipment, and destroy products.
Control programming still is programming, even if it uses nonclassical languages such as ladder logic, sequential function charts, function block diagrams, and procedure function charts. In addition, many control programs use classical programming languages like C, C++, C#, Java, Basic, and SQL. Also, we have a whole zoo of special purpose languages developed by tool and application vendors, often developed with little regard for language consistency, structured programming constructs, and object models, and with little available training and a small user base. Control programming is hard real-time, event based, and often mission critical. Errors in control programs can harm people, damage equipment, and destroy products. Unlike business system programming where you can roll back database changes and transactions, you can't roll back a chemical process or many manufacturing steps. Despite these problems, there are specific habits you can develop that will make you a better control system programmer. There is easily a 10x difference in productivity and quality from the average to the best control programmers and a 5x difference between average and worst. The difference is often based on the habits that the good programmers have that average or poor programmers do not, and the bad habits the poor programmers have.
Control programming is not an art, where creativity is king; or science, where discovery is king. It is engineering, which is creatively applying well-understood, proven, and workable solutions to new problems. In addition, programming requires more than just experience; it requires good design, coding, debugging, implementation, and personal and group habits. Ten years of experience, where the same year is repeated 10 times, doesn't count. Even one year of experience where you develop good habits will make you a better programmer.
Avoid a dozen bad habits
Avoid these dozen bad programming habits. Poor programmers:
- Repeat errors
- Produce inconsistent and ambiguous designs
- Don't leave time to update design documents
- Don't leave time to comment their code
- Don't leave time to break code into smaller manageable pieces
- Don't use version control or any form of source code control
- Don't ask for reviews, don't want them, and don't encourage them
- Commonly answer questions about the logic of their code by saying, "It's obvious"
- Never have time to do the right thing and are always patching and debugging previous work
- Fail to account for edge cases
- Spend a large percentage of time debugging their code
- Avoid recording their errors.
The most important programming habit to develop is the personal development habit of recording your own mistakes. Everyone makes mistakes when programming. It is intensely detailed work, where one character wrong in a 10,000-line program causes it to fail. Control programming also adds timing, real-time network communication, and data integration elements to an already complex task. Even the best programmers make mistakes in this environment, but the best programmers record their mistakes so that they learn not to repeat them. They don't just record the big mistakes, which may take days to debug, but they also record the small mistakes caught by editors, compilers, linkers, and unit tests.
Analyze and avoid
The reason for recording mistakes is to identify your weaknesses and to develop the work habits to avoid them. Some typical weaknesses are forgetting to initialize variables, using the wrong case for variable names, inadvertently changing a data type, not checking for in-range values before using them, and not checking for edge conditions.
Developing the good habit of recording your mistakes is easy; at the end of each day, or even two or three times a day, record what mistakes you made in a simple document. This includes how many times you had to run a program through a compiler or run a unit test to correct a small error. You may find that you regularly misspell variable names or don't close out conditional logic correctly. You will find over time that simply recording the mistakes makes you more aware of them and you will stop making them.
Take time to save time
Programmers who adopt this simple habit have discovered that their productivity improves dramatically. They spend less time performing small fixes to pass unit test, and their code has fewer hidden problems that don't show up until system test or installation. Once they recognize a pattern in design, coding, or unit testing that leads to complex errors, they can address the root cause instead of fighting the symptoms.
Good control system programming is hard, but developing the correct habits-in particular learning from your mistakes, large and small-will make you a better programmer, a better engineer, and a more valuable member of any development team.
Coming up: More good programming habits
Other good habits that programmers have fall into several categories: personal development habits, group development habits, design habits, coding habits, implementation habits, and debugging habits. Future columns will address good programming habits in each of these areas.
- Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering, firstname.lastname@example.org.
This posted version contains more information than the print/digital edition issue of Control Engineering.
At www.controleng.com, search Brandl for more on related topics.
See other articles for 2014 at www.controleng.com/archive.
See other Manufacturing IT articles.
- See related stories from Brandl below.
- Events & Awards
- Magazine Archives
- Digital Reports
- Global SI Database
- Oil & Gas Engineering
- Survey Prize Winners