What Version of Java Compiled This

I try to use the latest stable version of Java/JDK when I can. There are a lot of performance improvements in newer versions of Java. Newer versions of OpenJDK also allow usage of Java Flight Recorder (that's a big deal). So when I have to work with a new Java application I often start with a new version of Java and work my way down the list until everything works. This can be a painful experience. When I have less time I'll look up what version of Java was used to compile the application then use the same version to run it. Even if you do have free time this is a good idea because Java 8 and below is probably going to have problems running on Java 9 and beyond. A lot of core language classes changed.

You might be thinking, "Why is this?" That's a valid question. It comes down to poor testing. The people testing are using the same environment as the developers and don't see a problem. The class files provided by the JDK are available to the application to use. All required classes should have been bundled with the application, but if the issue isn't caught in testing then it doesn't happen.

Anyway, how to test this: if you have a JAR or WAR file unzip it. On Linux, you can just run the unzip command against the file: unzip example.jar. On Windows, if you have a third party application you can point it at the file. If you are using Windows' built-in zip handling then rename the file to end with a .zip.

Once the files are extracted navigate to a class file made by the provider of the application; something like, com/yoakum/oneZero/security/. On Linux run javap -verbose Example.class | grep "major" on Windows run javap -verbose Example.class | findstr "major". This will return a number which you'll match to the following table:

Class Major Version | Java Major Version
                 ...|...
                 15 | 59
                 14 | 58
                 13 | 57
                 12 | 56
                 11 | 55
                 10 | 54
                  9 | 53
                  8 | 52
                  7 | 51
                 ...|...

This isn't a problem unique to Java. Every programming language I've ever worked with has had this issue. Java shouldn't have this issue as badly as it does. And it wouldn't if businesses would put more effort into ensuring their applications were more fully packaged to remove risk of missing or conflicting versions of dependencies.

The Method Won't Save You

We have all heard the preaching of "method zealots" who say, "If you just adopt my method, most of your problems will disappear." Although many methods have been the subject of such ravings, the majority during the 1970s and early 1980s contained the word "structured" in their names. Those during the late 1980s through the early 2000s contained "object" in their names. And the methods from the mid-2000s to today contain the word "agile" in their names. Although each of these waves bring great insights, as well as quality-instilling software development constructs and steps, they are not panaceas. Organizations that are really good at developing quality software are good regardless if they use a structured, object-oriented, or agile methodology. Organizations with poor records will still have poor records after adopting the latest fad method.

As a manager, beware the false soothsayers who will promise great increases in either quality or productivity based on a new method. There is nothing wrong with adopting a new method, but if the organization has had productivity or quality issues in the past, try to uncover the source of that failure before you jump to a solution. It is highly unlikely that your method is to blame!

Reference:

Loy, P., "The Method Won't Save You (But It Can Help)," ACM Software Engineering Notes, January 1993.

Use An Appropriate Process Model

Dozens of process models are available for software projects to utilize: agile, waterfall, SAFe, throwaway prototyping, incremental development, spiral model, etc. There is no such thing as a process model that works for all projects in an organization. Every project must select a process that makes the most sense for it. The selection should be based on corporate culture, risk willingness, application area, volatility of requirements, and the extent to which requirements are well understood.

Study your project's characteristics and select a process model that makes sense. For example, when building a prototype, you should follow a process that minimizes protocol, facilitates rapid development, and does not worry about checks and balances. When building a life-critical product, the opposite is true.

References

https://www.geeksforgeeks.org/software-processes-in-software-engineering/

Alexander, L., and Davis, A., "Criteria for the Selection of a Software Process Model," IEEE COMPSAC '91, Washington, DC: IEEE Computer Society Press.

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.

Allocate Appropriate Resources

Artificially constrained schedules and inappropriate budgets will doom a project regardless of the quality of the people or the availability of tools, languages, and process.

If you try to compress either schedule or budget, the engineers working on the project will not work efficiently, there will be no wiggle room when the inevitable slippage occurs, morale will suffer, and the project will probably cost more than what would otherwise be considered reasonable anyway.

In short, tightening a schedule or budget to land a contract or to get stakeholder sign-off will only ensure your failure to deliver. The goal isn't to get project approval. The goal is to get approval for a project that can actually succeed.


Reference:
DeMarco, T., "Why Does Software Cost So Much?" IEEE Software, March 1993.

Minor Underestimates Are Not Always Bad

Assuming morale has not been diminished, members of a project that is perceived as slightly behind schedule will tend to work hard at catching up, thus increasing productivity. Similarly, members of a project that is perceived as slightly ahead of schedule often take vacation days, work less hours, read their email longer, and ease up in other ways, thus decreasing productivity. In other words, the cost estimation itself will affect the project outcome. Any specific project may expend less resources if it is slightly underestimated than if it is slightly overestimated.

Be careful, though! If project members believe that the schedule is ridiculously underestimated or that estimates are underestimated on purpose, then morale and productivity will decrease. Worse still, you, as a manager, might start to gain a reputation of being incompetent, manipulative, or both. If that happens then project members will begin to perceive all estimates, even good ones, as bad.

As long as a minor underestimate is a natural occurrence then there is no need to worry that it'll effect the schedule. Team productivity has a certain amount of flexibility to compensate as long as there are minor overestimates to balance things out.


Reference:
Abdel-Hamid, T., and Madnick, S., "Impact on Schedule Estimation on Software Project Behavior," IEEE Software, July 1986.

Reassess Schedules Regularly

Schedules are usually set at the beginning of a project. These include intermediate deadlines as well as the product delivery deadline. As each phase is completed, the schedule must be reassessed. A behind-schedule project rarely recovers during subsequent phases. Thus, a project that is, for example, one month late at completion of design will be at least one month late for delivery. In most cases adding or removing people will only delay the project further. The most common technique is not to change the product delivery date. (After all, we don't want to disappoint the customer just yet; they might stop paying.) As each intermediate milestone is missed by an increasing amount of time, the time allocated to testing is reduced more and more. At the end, one of two situations is inevitable:

1. The product is shipped without the necessary quality.
2. The customer is notified of a very large schedule slip very late in the project.

Neither is acceptable. As a manager, your responsibility is to prevent disasters.

Instead, establish a working relationship with customers and/or management levels above you. Report every possible date change (usually a slip) and discuss the alternative strategies for overcoming them. The Agile methodology is very keen to cut out features in order to hit delivery deadlines. Only early intervention and involvement by all parties can prevent slippage escalation.

Reference:

Shore, J., Warden, S., The Art of Agile Development, O'Reilly Media, 2008.

Gilb, T., Principles of Software Engineering Management, Reading, MA: Addison-Wesley, 1988.

Believe in the Schedule

Probability of Project Success

Once a feasible schedule is established and appropriate resources allocated, all parties must believe the schedule. Engineers will not succeed in meeting a schedule if they don't believe it is realistic. The probability of success is more a function of faith in the schedule than its realism

The best advice is to have engineers set schedules. Unfortunately, this is not always possible. The second best advice is to involve engineers in the tough trade-offs that occur between functionality, schedule, and project abandonment. Few engineers would rather lose their job because a project is canceled than strive to meet a tough schedule.


Reference:
Lederer, A., and Prasad, J., "Nine Management Guidelines for Better Cost Estimating," Communications of the ACM, February 1992.

Know Before You Count

"Know before you count" is a software development management principle simply stated by Gerald Weinberg as, "Before you can count anything, you've got to know something." He is talking about the many people who count things in software but don't know what they are counting. He provides a great example. We have data concerning what percentage of the software industry is involved with maintenance rather than development. But can we recognize maintenance? Is a "new" development that completely replaces an existing system considered maintenance or development? Is a "modification" to an existing system that doubles current functionality and removes 95 percent of old functionality considered maintenance or development?

When selecting metrics for your project, make sure that what you are measuring relates to what you are trying to achieve. This often entails using multiple metrics. Remember: Even if everybody is measuring something one way, that way is not automatically right for you. Think about your metrics. Since everything can be observed (and in most cases measured), carefully select what you want to observe (and measure).


References:
Stark, G., Durst, R., and Vowell, C., "Using Metrics in Management Decision-Making," IEEE Computer, September 1994.

Weinberg, G., Rethinking Systems Analysis and Design, New York: Dorset House, 1988.

Avoid The Impossible

This may seem like obvious advice. One the other hand, many projects commit to delivering their product on schedules that are 100 percent impossible. Barry Boehm has defined the "impossible region" as a relationship between the expected time to develop a product and the number of person-months (PM) to be consumed. Specifically, the elapsed time (T) from writing a software requirements specification to product delivery will not be less than 2.15 times the cube root of person-months, that is,

If you have a project that is estimated to take 5 person-months then this rule says that the project can't get finished faster than 3.7 calendar months.

Ninety-nine percent of completed projects have obeyed this rule. If you think you can do better then here are some ideas to revisit:

• Productivity and quality are inseparable
• Every complex problem has a solution

Reference:

Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981.

Software Cost Estimation Methods

Numerous cost estimation methods are available commercially. Each is based on data collected from a large set of completed projects. Any of these methods can be used to generate ball park estimates for your software development project. To use them to generate more accurate estimates, you must tailor them to your work environment. This tailoring adapts the model to your type of applications and tools. It eliminates variables that are invariant in your environment. It adds variables that are productivity-influential in your environment.

Chapter 29 of Barry Boehm's Software Engineering Economics explains in detail how to tailor the Constructive Cost Model (COCOMO) to your environment. Similar tailoring guidance is provided with other cost estimation methods. You must fully embrace the spirit of such tailoring, or you will end up with dismally inaccurate results.


Reference:
Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981.

Enneagram Test

A year ago I took an online Enneagram test. My top two personality types were:

1. The Achiever
2. The Perfectionist

Is it all mumbo-jumbo? Is it accurate? I don't know but that doesn't mean it can't be helpful. It is a good way to practice some self-reflection. It can act as an aid to give me some points to consider. You might find it fun to read the core values for each of the Enneagram types and consider which you most closely align with. Or try to develop your own core values. Doing so from scratch is a fairly difficult thing to do. There is nothing wrong from taking what you agree with from each of the Enneagram types.

Our beliefs change over time so it is valuable to test ourselves on occasion. I know my political beliefs have changed. The funny thing is that my friends noticed more quickly than I did. We hold onto labels even though our beliefs change and the labels become inaccurate.

Collect Data Unobtrusively

Data collection is extremely important to help with future cost predictions, to assess the current state of a project or organization, to assess the effect of a change in management, process, or technology, and so on. On the other hand, data collection in an obtrusive fashion -- for example, if it requires software developers to do considerable extra work -- is meaningless because its collection affects the data itself. Furthermore, data collected from developers who do not want to provide such data will likely be useless because it is unlikely that an uncooperative developer will provide meaningful data.

The best way to collect data is automatically, with no developer-perceived interference. Obviously you cannot do this all the time for all data, but you should automate data collection whenever you can. However, you must be careful not to cross any lines concerning privacy. Respect your employees privacy and be transparent about what and how you collect.


Reference:
Pfleeger, S., "Lessons Learned in Building a Corporate Metrics Program," IEEE Software, May 1993.

You Can Optimize Whatever You Want

Any project can optimize whatever factor of "quality" it wants to. In optimizing any one factor, other "quality" factors are generally denigrated. In a landmark experiment conducted by Gerald Weinberg and Edward Schulman, five teams of software developers where given identical requirements, but each was told to optimize something different: development time, program size, data space used, program clarity, and user friendliness. In all cases except one the programs produced by the teams where rated best in terms of the attribute they were told to optimize.

If you tell your people that everything (such as schedule, size, maintainability, performance, and user friendliness) is equally important, none will be optimized. If you tell them that only one or two are important and the rest unimportant, only the important ones will be addressed. If you give them an a priori relative ranking, the ranking may not be appropriate in all situations on the project. The fact is that there are trade-offs -- different trade-offs -- to be made constantly during product development. Work with your employees and help them understand your priorities and your customers' priorities.


Reference:
Weinberg, G., and Schulman, E., "Goals and Performance in Computer Programming," Human Factors, 1974.

Winter Reading Challenge

My local library is running a winter reading challenge. The challenge is to read five books that meet the following criteria between January 2 to February 29, 2020.

1. Listen to a Book



2. Teaches You Something New



3. Graphic Novel or Comic Book





4. First in a Series



5. In Another Time or Place



6. Book Club Recommendations (need to finish)



7. Author New To You



8. Outside Your Comfort Zone
• 
  
9. Under 200 Pages (currently reading)



10. Made Into a Movie (want to read)



11. Always Meant to Read
• 
  
12. Retelling of a Story





13. Set in an Imaginary World



14. Author of Color





15. Winter Setting
• 
  

The Ghost Map

The Ghost Map: The Story of London's Most Terrifying Epidemic--and How It Changed Science, Cities, and the Modern World by Steven Johnson
My rating: 5 of 5 stars

The story was great. You might be thinking, "I don't know about reading this. I've heard tons of 10 and 30 minute versions of this story. Is an 8 hour version worth it?" It is.

The last 20% of the book is the conclusion and it gets a bit off-topic. I don't think you'll really miss out on anything if you choose to skip it. There are good points made and discussed but if you're just here for the Ghost Map story then don't worry about it.

View all my reviews

Huge Differences Among Software Engineers

Productivity (measured by lines of code per person-month) can vary by as much as a factor of 25 from the most to the least prolific coder. Quality (measured by bugs found per thousand lines of code) can vary by as much as a factor of 10 from the best to the worst software engineers.

I'm sure you can see my bias in the words above that I think quality is more important than productivity. Unfortunately, I don't have data to see the intersection of those two measures. I suspect that there is a correlation between productivity and quality. But with a diminishing return where the act of writing more code prevents a person from thinking about the stakeholder's true intention or the ramifications of the new code.

As a manager, you have to encourage an optimal mix of productivity and quality. This isn't done just by focusing on a single software engineer. This is a whole team project. For example:

• If quality is down then consider requiring stricter code reviews.
• If productivity is down then consider lighter code reviews.
• If both are down, is your team overworked?
• If both are down, is your team in need of training?
• And, yes, sometimes you do have to single one person out and say, "Slow down. You are making too many mistakes." Or, "Speed up. You are spending too much time testing your code."
• I've heard both of those admonitions. They helped make me a better developer. They helped me find balance between getting stuff done and perfectionism.
• etc...

There is no right way to optimize a development team's productivity and quality. But there is a wrong way - deciding everything for yourself. No one has all the answers and even if they did it would upset the team members to have no input.

Talk to your team! Show them the data that has you concerned and ask for input. Share details about the budget to explain why sending a few people to the QCon conference in Tokyo isn't feasible but the whole team could go to KCDC. Find ways to combine team building with training.

Reference:
Sackman, H., et al., "Exploratory Experimental Studies Comparing Online and Offline Programming Performance," Communications of the ACM, January 1968.

Brooks' Law

Measuring a project solely by person-months makes little sense. If a project could be completed in one year by six people, does that mean that 72 people could complete it in one month? Of course not!

Suppose you have 10 people working on a project that is due for completion in three months. You now believe your are three months behind schedule; that is, you estimate you need 60 more person-months (6 months x 10 people). You cannot add 10 more people and expect the project to be back on schedule. In fact, adding 10 more people would likely delay the project further due to additional training and communications overhead.

Approximately a decade ago, I worked on a big project alone. I approached it as proof-of-concept and focused on getting everything to work. Since ensuring that everything worked was my goal I didn't devote a lot of time to good object-oriented programming practices... I'm not going to apologize for that. I still think I did the right thing to ensure that the project worked. Half of the work I was doing was testing another team's API and helping them get it right. However, the project managers really screwed me over by announcing the project finished when reality I had only finished testing the API provided by the other team. My boss put 20 people on the project to finish it in the next month. This could have been a disaster but she did an amazing job coordinating everyone's efforts. While all those people were helpful with writing documentation and performing testing while the code was being rewritten. It really came down to one person, Charles Forsythe, who took the largely procedural code that I had written and turned it into high quality OO code.

This project would have gone more smoothly had we intentionally planned to throw away my prototype. Also, it is generally a bad idea to try to retrofit quality. It is either a testament that my prototype was of high quality code just not of the required OO paradigm and/or that Charles' coding ability overcame the difficulty of performing a retrofit.

The point of that story is that from the outside it looks like 20 people were thrown at the project to finish in a month. In reality, 1 person finished the project in a month and 19 people cleared the way and focused on tasks that multiplied that 1 person's impact. By doing it this way, my manager avoided the additional training and communications overhead. If they all would have tried to develop code for the project then it would have failed due to Brooks' Law. This isn't a guaranteed way around Brooks' Law but it is a good way to reframe development problems.


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

Keep The Office Quiet

The most productive employees and companies have quiet and private offices. They have phones that can be silenced or diverted. They are insulated from regular, nonbusiness interruptions. Contrast this with the general industry movement toward open, landscaped offices, which reduce physical plant cost but dramatically decrease productivity and quality. Of course, the usual management line is that such an arrangement "facilitates communication." Not true. It "facilitates interruption and noise."


Reference:
Tank, A., Why It's Time to Ditch Open Office Plans, 07-Feb-2019. [Online]. Available: https://www.entrepreneur.com/article/327142. [Accessed: 22-Jan-2020]

McGregor, J., Open office plans are as bad as you thought, 18-Jul-2018. [Online]. Available: https://www.washingtonpost.com/business/2018/07/18/open-office-plans-are-bad-you-thought/. [Accessed: 22-Jan-2020]

James, G., Open-Plan Offices Kill Productivity, According to Science, 18-May-2017. [Online]. Available: https://www.inc.com/geoffrey-james/science-just-proved-that-open-plan-offices-destroy-productivity.html. [Accessed: 22-Jan-2020]

DeMarco, T., and Lister, T., Peopleware, New York: Dorset House, 1987.

The Like Switch

The Like Switch: An Ex-FBI Agent's Guide to Influencing, Attracting, and Winning People Over by Jack Schafer
My rating: 4 of 5 stars

Very actionable advice... but a strong undertone of endorsing the idea of lying to people. Please only use Schafer's advice to make real friends and to bring joy to coworkers. Befriending people purely for selfish gains is wrong.

Use his advice to get past those first difficult times of getting to know someone. Make a good first impression then be yourself.

View all my reviews

Carry The Water

When your people are working long hours to get a software engineering job done, you should work the same hours. This sets the right example. Your employees will be more willing to work hard and do a good job if they know you are in the predicament with them. I had a software development manager, Karen Bolda, that did precisely this. It made all the difference in our attitude. During crises, Karen took on the role of "working for her employees." It worked.

If you can't help with the engineering work itself, let them know you are available to coordinate effort, run errands, order food, whatever they need. In short, carry the water.

Communication Skills Are Essential

When recruiting personnel for your project, don't underestimate the importance of teamwork and communication. The best software architect becomes a poor asset if he or she is unable to communicate, convince, listen, and compromise.

Communication breakdowns can occur at any process level. The effects of these problems are not independent. For instance, fluctuating requirements increase a development team's need for communication both with customers and with the project's other teams.

Exceptional architects are skilled at communicating their technical vision to other project members. They usually possess exceptional communication skills and often spend much of their time educating others about the application domain and its mapping into computational structures. In fact, much of their design work is accomplished while interacting with others. The integrative role of an exceptional designer compounds itself. This happens because those perceived as most knowledgeable will become communication focal points, providing them more knowledge about the system to integrate into a more comprehensive model.


Reference:
Curtis, B., Krasner, H., and Iscoe, N., "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, November 1988.

Expect Excellence

Your employees will do much better if you have high expectations of them. Studies by Warren Bennis prove conclusively that, the more you expect, the more results will be achieved (obviously with some limit). In many experiments, heterogeneous groups were divided into two subgroups with identical goals. One subgroup was treated as if excellence was expected. The other subgroup was treated as if mediocrity was expected. In every experiment, the group for whom excellence was expected outperformed the other group.

You can show in many ways that you expect excellence: Be an example (work hard, be proud of your efforts well done, don't play computer games on the job). Provide educational benefits to your employees to help them achieve their best. Reward excellent behavior.* Coach, tutor, cajole, and attempt to inspire your poorer performers toward better work products and habits. If you (or they) fail, find more suitable opportunities for them within your organization or your company. If all else fails, help them find a job outside. You cannot allow them to stay in an inappropriate job, but you must also show compassion. If you leave them where they are, your product will be of lower quality and your other employees will assume that poor performance is acceptable.


Reference:
Bennis, W., The Unconscious Conspiracy: Why Leaders Can't Lead, New York: AMA-COM, 1976.

Tehanu

Tehanu by Ursula K. Le Guin
My rating: 5 of 5 stars

This is an excellent "see the world through someone else's eyes" book. There will be parts that might be distasteful but that's how parts of people's lives are. Another person's opinions might not be correct but they exist nevertheless. I found the afterward really interesting. The way the author talked about writing the book made it sound like a process of discovery instead of creation.

View all my reviews

Trust Your People

In general, if you trust people, they will be trustworthy. If you treat people as if you don't trust them, they will give you reason not to trust them. When you trust others and give them no reason not to trust you, they will trust you. Mutual trust is essential for successful management.

When one of your employees says, "Can I take off today at 2:00 PM? I'll work a few hours extra later in the week," you should say, "Yes." You lose nothing, and you gain the loyalty and respect of your employee. There are many more opportunities to be the bad guy than the good guy. Take every chance you can get to be the good guy. Who knows, maybe in a few weeks you'll need to ask the employee to work a few extra hours for a job you need to have done.


Reference:
McGregor, D., The Human Side of Enterprise, New York: McGraw-Hill, 1960.

Listen To Your People

The people who work for you must be trusted. If they're not trustworthy (or if you don't trust them), your project will fail. If they don't trust you, your project will also fail. Your people can tell as quickly that you don't trust them as you can when your boss doesn't trust you.

The first rule of trust is listening. There are many opportunities to listen to your people: when they visit your office to tell you about a problem they are having, when you need an estimate from them for a software development, when you are managing by walking around (MBWA), among others. Whenever your people are talking to you, listen and hear. They consider what they are saying to be important or they wouldn't be telling you. There are many ways to let them know you are listening: eye contact, appropriate body language, "playing back" what you think you heard them say, asking appropriate questions to solicit more information, and so on.


Reference:
Francis, P., Principles of R&D Management, New York: AMACOM, 1997.

2020 Reading List

I was continuously updating and referencing this list to guide my reading. Therefore, I decided it was more useful to make it a page instead of a post with a link on my blog's landing page.

https://jerryyoakum.blogspot.com/p/2020-reading-list.html

Grain Brain

Grain Brain: The Surprising Truth about Wheat, Carbs, and Sugar--Your Brain's Silent Killers by David Perlmutter
My rating: 3 of 5 stars

A lot of reviewers complain that this title is very repetitive. It is but for the audiobook that is alright. It is very easy for much of what the author wrote to slip right by especially if I'm doing other stuff while listening. I'm not convinced that this diet is for everyone, but I am convinced that for the people who need this diet that it is life changing. I'll change my food choices some based on this book and definitely watch for future news on this topic.

View all my reviews

Mycroft and Sherlock

Mycroft and Sherlock by Kareem Abdul-Jabbar
My rating: 5 of 5 stars

Great job of portraying a young Sherlock and explaining why Mycroft didn't go on to more adventures like he had in the first Mycroft book.

View all my reviews