Credit: /dev/solita

Refactoring not only helps improve the mechanical quality of code; it also helps you learn from your code. When refactoring, you converge on better models. Right now, your code works, but it may feel tense, even a bit brittle. Refactoring reveals the implicit model, which informs your understanding of the domain. In the test-driven development cycle of red-green-refactor, “refactor” is not optional, lest you accumulate technical debt and fail to learn from the coding experience. 15 signs you’re doing agile wrong, Steven A. Lowe, InfoWorld, May 26, 2016.

What was that word? Refactoring? You mean just restructuring my programming code? Why do we need a new word? We always seem to make things overly complicated!

I learned to program in high school at a time when it was not normal to have the ability to learn programming in high school. The language was Montana State Basic. We entered programs typed up on paper tape into teletype machines. I loved it.

I was a stream of thought programmer. If an idea came to me I would just start writing code. As the code formed and the ideas came out I would notice patterns. I would notice that I was coding the same things multiple times. Seeing that, I would take the code and put it into a subroutine (a gosub!) and then invoke it when I needed it. Towards the end of my programming I would be doing more restructuring of my code, moving things around and combining things, than I would be typing in new code. This whole process of restructuring helped refine my ideas into a clean, organized structure. My coding restructuring thereby became my design process.

Years later I would learn many types of design methods (object oriented, entity, patterns, etc.) but I always felt they were unsatisfying. They were unsatisfying because they held back my urge to just get in there and start coding to see my ideas in action. I would hear that if I wrote code without a documented design that it would be fragile, would not be maintainable, would not be extendable, and well, all sorts of horrors would occur. As I moved more into management and programmed less, I was actually kind of happy that I wouldn’t have to experience losing my passion for programming because of all that up front preparation we were now having our programmers do.

As a manager, however, I still needed to do a lot of programming. Much of what I did to manage every day required pulling together data to get a big picture of how the project or department was doing and then pushing out that data to all the teams and stakeholders who needed it. These were manual processes that I then wrapped some code around (VBA, Snobol, etc.) to make them faster and more reliable to get the information we needed. This coding was, once again, done in a stream of thought manner. It just matched how I would do the work as a manager to get the data I needed (e.g., go to this site, download this data, get these logs, collate these status reports, etc.). My daily management tasks certainly weren’t designed up front and in a document! Most weeks I found myself tweaking the code to adapt to something new I wanted to do. On occasion I would sit down and “refactor” to clean up the code, seeing new patterns that could be organized and grouped together logically.

Organizing my daily management tasks by automating them made those tasks clearer in my mind. By having to make the micro decisions on what I wanted my code to do, I had to make decisions about how I managed. This mutually beneficial process (my code and my management) simply made everything better and more clearly defined. When someone asked me for help on managing their project or department it was much easier to assist because my processes were well defined and I had tools that helped me do them (I described them as “power assisted management!”). When I was asked to change a project or how my department operated (resource, budget or mission change), I could readily adapt and quickly provide the expected impact of the changes. I recall one case where we were given a week to show how we planned to handle some cutbacks. I had my response within a day. After a week, when most of the other managers still had nothing, my boss told me he wouldn’t “penalize” me for managing my department well (i.e., he could have cut from me and would known the impact with confidence). Instead he cut the resources from the other departments and told them to figure out how to still get the job done — since they didn’t know how they were getting their job done now anyway!

Refactoring or restructuring one’s daily work on a regular basis is a useful project (or department or coding) management tool. It can help us to keep sharp and to keep improving on how we do business. Just like in software coding, if we don’t arrange the time to periodically think about and clean-up what we are already doing, it can slowly turn into a fragile process and a growing source of daily unnecessary crises.

What are you doing to ensure that how you manage everyday continues to improve and to become more robust and more resilient to daily shocks?

See for example How To Be Able to Give Your Boss A Quick Estimate