Community Adoption of New Practices

Community adoption of new practices can mean a lot of things.  From getting a small team to try a new methodology or tool to convincing the world that a product or service is needed.

In 1996, Robert Metcalfe was awarded the IEEE Medal of Honor for "exemplary and sustained leadership in the development, standardization, and commercialization of Ethernet." The story of how Ethernet came to be follows the 8 steps of essential practices below. I've added headings for what departments typically handles each practice in a large company. You don't have to have different people or departments. I find it helpful to get into the mindset of each role when implementing a specific task.

• Product Management
• Sensing -- giving voice to a concern over a breakdown in the community
• Envisioning -- design a compelling story about a future without the breakdown
• Development
• Offering -- committing to do the work to produce that feature
• Sales
• Adopting -- gaining commitments from early adopters to join the innovation for a trial period
• Sustaining -- gaining commitments from majority adopters to join the innovation for an indefinite period
• Implementation
• Embodying -- working with the community until the new practice is fully embodied, ordinary, and transparent
• Navigating -- moving ever closer to the goal despite surprises, contingencies, and obstacles
• Marketing
• Mobilizing -- building a network of supporters of the innovation from within dispersed communities

Many times over my career I've been assigned the job of getting multiple software development teams to adopt a practice; coding standards, secure coding practices, SOX requirements, architectural guidelines, etc. Eventually, the above 8 practices were performed but not always in an order that was useful. I got better with experience, but my life would have been easier if I would have had those practices written down to guide me. To make notes against. And to revisit when progress was slow or stopped. I hope you'll save the above list and use it for your future innovations.

References

Denning, P., "Avalanches Make Us All innovators," Communications of the ACM, Vol. 63, No. 9 (Sept 2020), 32 - 34.

Sorry, I don't have a reference for Metcalfe's Ethernet story. I heard him talk about it at a conference in 2015 or 2016.

Misbehaving

I've been listening to Misbehaving: The Making of Behavioral Economics by Richard Thaler on audiobook. In chapter 3, "The List," there is an interesting analysis of a company losing money because managers are afraid to lose their jobs. Which leads them to avoid some projects. I saw this only a little in my work experience.

In chapter 29, "Football," there is an analysis of how to game the draft to end up with an overall better team. Basically, it is chapter 3 but told in a more interesting manner. Replace the star football player with the star project and you get the same problem of putting all your resources in one basket. The analysis goes deeper and points out that the coaches and managers are not solely to blame. They are going after the star players (star projects) because these are what the owner (CEO/chairmen) want. I saw this more often in my work experience.

The higher up in a company the less the employee looked at the project data and the more they looked at what their boss wanted. If you are a manager, director, VP, C-suite employee, or chairman then please read this book. It won't give you answers but it might force you to acknowledge that you are making decisions based on the wrong data. Then you can give the company a better chance at [overall] success.

Okay, I know, I'm skipping over the problem of "the manager who doesn't work on the boss' pet project still gets fired." Yeah, that sucks. You deserve a better boss. But guess what? You saved your department for another year and only had to sacrifice yourself. Had you done the doomed project you might have doomed the department too.

Understand Risks Up Front

On any software project it is impossible to predict exactly what will go wrong. However, something will go wrong. In the early stages of planning, delineate the largest risks associated with your project. For each, quantify the extent of the damage if the risk potential becomes a project reality and also quantify the likelihood that this will come to pass. The product of these two numbers is your risk exposure with respect to that particular risk.

At project inception, construct a decision tree that delineates all the things you could do to lower the exposure. Then either act on the results immediately, or develop plans to implement various actions at points when the exposure exceeds your acceptable limits. (Of course, specify in advance how you will recognize this situation so that you can implement the corrective action before it is too late.)

Reference:

Charette, R., Software Engineering Risk Analysis and Management, New York: McGraw-Hill, 1989.

Fix Requirements Specification Errors Now

Errors in the requirements specification will cost you:

• 5 times more to find and fix if they remain until design.
• 10 times more if they remain until coding.
• 20 times more if they remain until unit testing.
• 200 times more if they remain until delivery.

That is more than convincing evidence to fix them during the requirements phase!

Start using your software architects and key software engineers to review software requirements before they go to development. Don't do this as a waterfall process where the SRS goes from Product to Architecture to Development. Make it an agile process where people get involved before the SRS is "done." It will make changes easier and less painful.

PROTIP: Put the SRS in a version-control system such as GIT with each section a separate file. This way anyone can make changes to the SRS that can be reviewed, approved, and tracked. Add in a script to combine the sections into a single file for easy handling. Everyone knows that this can be done but I have yet to meet a single product management team that does it.

Reference:
Boehm, B., "Software Engineering," IEEE Transactions on Computers, December 1976.

Top 10 Project Management Risks

As a software architect, I've assisted in project management and filled the role of product owner. For all of these roles it is important to be familiar with the situations that most often cause software disasters. These are your most likely risks, but not all of them:

• Personnel shortfalls
• Unrealistic schedules
• Not understanding the requirements
• Building a poor user interface
• Trying to gold-plate when the customer doesn't want it
• Not controlling requirements changes
• Shortfalls of reusable, interfaced components, or microservices
• Shortfalls in externally performed tasks
• Poor response time
• Attempting to exceed the capability of current computer technology

If you don't already have one, this list is a good starting point for a project planning checklist. Additionally, you should add risks unique to your environment, industry, and project then develop plans on how to mitigate them.

Reference:

Boehm, B., "Software Risks Management: Principles and Practices," IEEE Software, January 1991.

Hard Drive Cloning

TL;DR

Stuff that didn't work:

• Bootable USB drive with cloning software on it
• Samsung disk cloning software
• HDClone
• MiniTool Partition Wizard 12.0 (Demo)

Stuff that worked:

• Macrium Reflect
• Macrorit Partition Expert v5.3.9

-------------------------------------

A friend had some computer trouble. Lots of errors popping up on startup, applications refuse to update, warning messages about failed OS updates, etc. All of which is due to a good configuration idea that fails in practice. He had a 128 GB SSD and a 1 TB HD. Ideally, only the OS would be installed on the SSD and everything else would be saved on the HD. But that didn't happen. The software defaults all pointed at the SSD so when he installed an application, downloaded music, uploaded photos, etc it all went to the SSD. Even if he would have been doing it all the "right" way, the Windows 10 footprint is quite large and the 128 GB SSD would probably have been getting crowded.

I offered to clone his 128 GB SSD onto a 1 TB SSD to resolve the root problem.

Option #1:

I came prepared with a bootable USB drive with disk cloning software on it.  But his computer refused to boot from the USB port. In fact, his computer wouldn't even display the BIOS settings unless a hard drive was connected. Weird.

Option #2:

I had some Samsung disk cloning software from a previous purchase. I cleared some spaced on this computer and installed it. It refused to acknowledge the Crucial SSD that I was upgrading to.

Option #3:

Ran HDClone 8 (Free Edition) to clone to the new drive. There is a popup on application startup that warns that the program has been intentionally hobbled to run slow unless you pay for the "enterprise" edition. Cloning to the new drive took one hour and 15 minutes. When it finished it warned that there had been numerous errors and claimed that the source drive was corrupt. I tried booting with the new SSD and as expected it wouldn't boot. Worse yet, Windows couldn't format the disk and Macrium Reflect would freeze trying to read the drive.

At this point, I believed the 1TB SSD was bad and replaced it with a Sandisk 980 MB SSD.

Option #4:

More than two hours had gone into this project and I was getting a little desperate to speed things up. I put Clonezilla on my USB drive and tried to boot from it. Once again, the computer refused to boot from USB.

Option #5:

I accepted that this would be a slow process and used my own laptop to image the 128 GB SSD using Macrium Reflect. My laptop is a cheap thing that was intended only for watching DVDs, Netflix, and Internet browsing. It only has USB 2.0 ports. However, there is something to be said for the adage, "Slow and stead wins the race."

Imaging the drive took approximately 1 hour. That tells you that the HDClone 8 (free edition) artificially slows things down to USB 2.0 speed. Next, I restored the image to the 980 MB SSD. Grrrr! There is no option to adjust the partition sizes. I tried several pieces of software to resize the partitions but they would stop just short of doing anything then say, "You have to purchase the professional version of this software to perform this action." Eventually, I found Macrorit Partition Expert v5.3.9 which allowed me to resize the partitions and fully utilize the SSD.

Macrorit Partition Expert v5.3.9 also was able to wipe the Crucial 1 TB SSD that had been fubar'd in option #3. It appears that there is nothing wrong with the drive.

I put everything back together and my friend's computer is working well. I left it happily downloading and installing the multiple gigabytes of Windows updates that it was behind on.

Avoid Standing Waves

One of the odd side-effects of keeping your plans up-to-date is the standing wave. In this situation, you always plan to update your plans over the next few weeks. Since projects that are behind schedule tend to get further behind schedule, this "update the plan soon" strategy requires larger and larger resources to be applied over the next few weeks. The wave gets larger and larger with no corrective action taken. Rescheduling and replanning in general require action, not just promises that things will be fixed soon. Just because you are only a few days behind, don't put off updating the plan. All projects fall behind one day at a time.

Reference:

Brooks, F., The Mythical Man-Month, Reading, MA: Addison-Wesley, 1975.

Keep Your Plan Up-to-date

You must plan a software project; however, having an out-of-date plan is even worse than having no plan at all. When you have no plan, you know you are out of control. When you have an out-of-date plan, you may naively think you are under control. So whenever circumstances change, update your plan. Such circumstances include changes to the requirements, a schedule slippage, a change in direction, finding excessive errors, or any deviation from the original conditions.

A well-written plan should enumerate the risks, the warning signs that the potential risk is becoming a threat, and contingency plans to put into place to reduce the threat. As a project progresses and predicted risks become threats, the contingency plans are implemented and the project plan is updated. The real challenge occurs when unforeseen changes occur. For these times, one often needs to replan the remainder of a project in its entirety, with new assumptions, new risks, new contingency plans, new schedules, new milestones, and so on.

Reference:

Reifer, D., "The Nature of Software Management: A Primer," Tutorial: Software Management, Washington, DC: IEEE Computer Society Press, 1986.

Quantify Requirements

All to often terms such as "fast," "responsive," and "extensible" are listed as software product requirements. Software architects often spend a lot of time helping product owners turn these desires into objective requirements. We do this by asking a lot of questions: How often? How many in what period? Increasing or decreasing at what rate?

It is a process that most product owners find maddening. Which is why it is important to explain that an exact answer is not expected. In fact, an exact answer would be a little worrying and I'd want to know how they got it. It is that process of how to get quantitative criteria that often needs to be explained and planned for. Finding ranges for quantitative requirements and checking against them is a time-consuming and expensive process. If no one wants to spend the time, effort, and money to do so then it reveals that the requirement isn't actually needed.

Focus your efforts on the parts of the system that stakeholders actually consider worth paying for.

Plan A Project In Detail

Every software project needs a plan. The level of detail should be appropriate for the size and complexity of the project. At an absolute minimum, you will need:

• A PERT chart showing the interdependencies among tasks.
• A GANTT chart showing when activity will be underway on each task.
• A list of realistic milestones (based on previous projects).
• A set of standards for writing documentation and code.
• An allocation of people to various tasks.

As projects increase in complexity, each of these requirements becomes more detailed and more complex, and other documentation becomes necessary. A project without a plan is out of control before it even starts. As the Cheshire Cat said to Alice in Wonderland, "If you don't know where you are going, any road will get you there!"

Reference:

Glaser, G., "Managing Projects in the Computer Industry," IEEE Computer, October 1984.