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 everyday 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 it 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 and 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!”).  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 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. But did we really need a new word?

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

Photo by Nathan Dumlao on Unsplash

“It’s almost like a dark state going on in Tallahassee,” said Rep. Carlos Trujillo, a Miami Republican and critic of the “culture of Tallahassee that compromises the process” because “priorities are shaped not on policy, but on relationships. MiamiHerald.com, Nov 5, 2017, Code of silence is breaking on Tallahassee’s sex secrets.

I love a good rule or policy. A clear policy that captures what we want to be doing now. A precise rule that if most people follow it the project would be successful. However, I also like to argue that we need to be flexible regardless of what the law, regulation or policy seems to say.

So we have the classic balancing act between two ends of a spectrum. Some people need the assurance of an absolute rule, while others want general guidance on what to do most of the time, and final others who don’t want to be hindered by any rule of any kind.

For example see Your Project Needs Business Rules, Not Meetings

So when I see an argument that is centered on someone not following a policy, I’m initially always skeptical. If the consequences of not following the rules are not being discussed, only the fact the rule was not followed, then I have great doubts that the arguer had any real case behind their concern. If we don’t know the underlying reasons for a rule, the real reasons, then for me the rule is at best a suggestion. This predictably drives some people crazy.

So while I love a few good rules, rules in general I see as suggestions and candidates for being updated to become better rules. Having priorities for example, based upon something other than possibly outdated policies doesn’t strike me immediately as a huge issue.

Are you basing your project on rules you understand and that make sense or are you just following the rules as the safest path just in case anything goes wrong or to avoid criticism?

Yet Abt, on behalf of Carthage College, in Kenosha, Wis., has returns that beat Harvard ’s $37 billion endowment and most others. In the 10 years through the most recent college fiscal year, ended on June 30, 2017, the former beer company executive racked up a 6.2 percent average annual return, according to the school. That performance is better than 90 percent of his peers, based on data from the National Association of College and University Business Officers. Harvard’s endowment, the nation’s largest, averaged just 4.4 percent a year in the same period, in part because of heavy losses on investments in timber and farmland. At Carthage, Abt’s approach was more pedestrian: mostly low-cost, market-tracking index funds from Vanguard Group Inc., the same funds used by legions of do-it-yourself individual investors. Why isn’t reliance on indexing more common among those who oversee the nation’s half a trillion dollars in college endowments? “Maybe it’s too simple,” Abt says. Bloomberg Businessweek, May 7, 2018. Beating Goliath.

I heard it all the time. Something like: “we have to tell the projects to do something different, because that is why this oversight committee was created!” In another case a team was formed by the quality department to evaluate how well we were prioritizing fixing the defects we were finding in our product. By the time the team reviewed and argued the existing priority and then assigned a new one, we had often already fixed the defect. When I had pointed this out to the team’s lead, he responded that they still had to make changes in priorities, because that was why management had asked them to form this team.

In another example, we simply showed management the average time it was taking to develop a feature, fix a defect and complete a product. The simple averages were just unbelievable to them. They were unbelievable because they were too simple and they immediately exposed the fact that all the promises we had made would fail based upon these numbers. The fact that we always delivered late and buggy products did not deter them from arguing that the averages could not be right because they suggested we would not deliver on time … which had been always true!

Compare with projects on steroids

Similarly, “Publish or perish” type philosophies (education, media) have motivated a glut of articles that probably didn’t need to happen. A financial advisor, Mark Hurlburt, whose specialty was tracking the success of other financial advisors’ recommendations, admitted that he published monthly not because there was that much new fundamentally but because people wanted to hear from him at least monthly.

On this site, I regularly advocate maybe a dozen related concepts of project management, over and over and over again. This repetition is in part because there is not a lot new. Fundamentals are fundamentals and are often pretty simple. Luckily, the real world continues to provide a lot of good and bad examples of these basic project management concepts. As someone once said: “we need reminding more than we need new learning.”

However, just hearing the same old stuff gets pretty boring, so we inevitably do something to try and distinguish what we are doing from what someone else is doing. This leads to a lot of noise and dubious claims of something “new and better.” Nevertheless, the insight that much of our fundamental knowledge just needs to be followed with vigor (e.g., study hard, exercise regularly, invest broadly, etc.) is not nearly as motivating (especially when it is hard, such as dieting or finding the root cause of a defect) as that allegedly new and sexy idea that someone else is touting.

What well known simple fundamentals should you be concentrating on to ensure your projects are ultimately and consistently successful?

The Air Force has revoked more than 226 Air Force instructions deemed unnecessary or outdated over the past year as part of its ongoing effort to get rid of so-called “queep.” In an interview at her Pentagon office Tuesday, Air Force Secretary Heather Wilson said the rescinded Air Force instructions contained 4,795 individual rules, or “compliance items,” that no longer need to be followed. AirForceTimes.com, August 29, 2018, Air Force Cuts 226 AFIs in Latest Salvo Against Hated Queep. Tech. Sgt. Kevin Wallace/Air Force illustrative photo

They had expected me to just go through the motions as had everyone before me.  Instead, I read the complete Air Force instruction or regulation and made sure I understood what it wanted and why. In some cases, I was even able to dig up the US congressional testimony that motivated what eventually became the instruction or regulation. In many cases, there was a very good reason for what was required.  Too often, however,  it was just silly stuff that added no discernable value and was seemingly written by someone with either no clue at what they were doing or else some bureaucrat with too much time on their hands trying to justify their existence.

Taking the time to clean out the junk in a project is an unexpectedly useful activity. I’ve gotten rid of unproductive reviews and meetings. I’ve done away with useless charts, graphs, and reports.  I’ve let contracts quietly lapse and did not renew them.  I also often took a lot of heat for doing these things but in the end, taking the time and effort to get rid of things that didn’t need doing paid dividends in the future in terms of efficiency and productivity because we didn’t have to mess with them anymore.

See Stop Doing That as a project management tool

Note, this is different than just ignoring the activity and letting it hang over the project. The Air Force didn’t have to take the time and effort to rescind the instructions. They could have just ignored them, which I suspect was already happening and pressed on with the mission.  As simple as this seems it turns out that taking the time to remove the unnecessary activities and their written directives save a surprising amount of time and effort in future projects.

At one of my Air Force assignments, we had a problem. The problem was that we had storerooms and cabinets filled with excess or obsolete PC equipment and software boxes. In one case there was a closet that literally had printers stacked to the ceiling because we had installed a local area network and could now share a few high-quality printers. All the individual printers that had come with each PC on this contract, before the days of local area networks, were no longer needed and were taking up valuable space in the offices.  There was a prescribed way of disposing of excess equipment in the Air Force and it, of course, was based upon an Air Force Instruction and required paperwork and arranging shipping to remove the equipment.  Not surprisingly, it seemed easier to not declare the equipment as excess and instead just hide it away somewhere.  When we finally dealt with the problem,  we were no longer periodically stressing out over the undeclared excess equipment and all the space it was taking up was now available for current mission activities.

See Provide A Service for the creative way we fixed our excess inventory problem.

Are you allocating time to clean out the unnecessary clutter in your project?

IT [Information Technology] use in the healthcare industry has experienced tremendous growth and attention since 2007. Yet concrete and credible evidence that HIT improves health outcomes remains inconclusive. Our investigation of New York State healthcare providers further indicates the healthcare industry may be experiencing an ongoing HIT productivity paradox, mirroring earlier patterns in manufacturing and other industrial sectors. While potential HIT contribution to health outcomes remains an open question, we suggest a collective approach is needed to address the many issues raised by the HIT productivity paradox and hope our research invites further inquiry into this important issue. Communications of the ACM, October 2018, The Productivity Paradox in Health Information Technology. Image: group50.com

I learned about this productivity paradox at the Software Engineering Institute. It was a revelation that helped me remain patient and less frustrated on future efforts.  The simple, now obvious, fact that when we do something new we will not necessarily be as productive as we had been in the past is an incredible insight.  There are ways to minimize productivity reduction during the early use phase, but it almost always happens.  There are times when using a new technique or technology that one’s productivity skyrockets.  When I first used a Palm Pilot and when I tried  Quicken financial software, I was more productive than previously with each keystroke.  These techniques or technologies embody a deep understanding of how an individual works, or at least of some individuals who then immediately resonate with the new approach.

The other issue mentioned here was, that beyond productivity, did the new technology ultimately result in improved health outcomes.  Google has pushed speed for websites, citing studies showing that speed maintained engagement by customers which resulted in higher revenue (at least for their ads, I suspect).   Some productivity enhancements just allow us to do the same job faster and more accurately, without necessarily being more profitable or health enhancing as covered in this article.   This is almost always a good place to be except in the rarer circumstance where over automating a bad process just made that process harder to improve later (I think of Tesla’s manufacturing line tents after robot automation did not live up to expectations).  Once we got good at what we did, in my experience, the easier it was to improve how we executed a project and then delivered more functionality, with higher quality, and on time and at or below our estimated cost.

Are you accounting for the temporary productivity drop in your improvement project?