The Cost of Corporate Education

There is a problem. The issue is that employee education and training are seen as costs rather than investments. That’s just a symptom of the real problem.

I’ve spent a lot of years doing consulting, project management, and corporate training to Fortune 500 companies. I’ve seen it over and over. I’ve also experienced it personally. I have seen companies sign their employees up for training. They are in class, and then they get pulled out ‘to fight a fire’ or to attend a ‘weekly con call’. Hm… What does this say about the company’s priorities? They’ve already spent the money on training, but the con call is more important? The company didn’t have someone to backfill the ‘fire’? Short term goals vs. long range planning. It results in wasted money and frustrated employees.

The problem is that companies, both large and small, perceive employees from the perspective of businesses that existed in the 1920-1950s. Technology, culture, and products change. Businesses, to a great extent, apparently don’t.

Henry Ford invented the assembly plant as you probably know. It was an amazing innovation since it allowed cheaper products that could be delivered faster. (You can consider Henry Ford the first proponent of Lean, but that’s an aside.) The not so obvious other result of the assembly line is that it allowed for the easy measurement of and quantification of employee productivity. The assembly line and factories could easily measure how productive any given employee was based on how many widgets they installed, or produced. ‘Piece work.’ Employees got paid based on how many widgets they produced. The more you produced, the more you made, and the more productive you were perceived.

Employees spent most of their lives producing widgets, and if they wanted to succeed, they tried to eke out as much time as possible. This didn’t leave a lot of time for self-improvement. How do you measure the ‘productivity’ of programmers, consultants, or other ‘soft’ delivery employees? We need a new term.

There is another problem. Companies don’t like to change. The larger the company the less change they can either afford monetarily or tolerate due to internal processes, design by committee, the desire for internal consensus, and inertia. ‘We have always done it that way…’ It’s as difficult to change the direction of a large corporation as it is to rapidly change the direction of the Titanic. Another aspect of this that I’ve seen is the ‘If it’s not broke, don’t fix it’ philosophy of business. ‘If the assembly line worked for Henry Ford and my grandparents, it will work for me.’

You may argue that by training your employees they will be better able to do their job. Again, how do you quantify that. The perspective that everything needs to positively impact the bottom line stems from having to measure everything in terms of widgets, money and profit. Don’t get me wrong, and don’t take this out of context. I’m all for money and profit’it’s important. It is, however, not the only measure of success. Companies don’t measure ‘success’, they measure bottom-line metrics.

‘Human resources.’ Things that you can measure. ‘Personnel’ sounds more human, doesn’t it?

Education and training are investments. It’s a long-term perspective ‘this will help you solve problems and be more efficient in the future’, rather than the short term perspective of ‘what did you produce in the last week.’ Why do you send your kids to school? They aren’t productive when they are in school…

Another failure I see in a company’s approach to education, is employees are often sent to a class ‘because my manager told me I should take this class.’ That’s better, but really’talk about student motivation. The student doesn’t want to be there. The manager believes the information will help the employee be more productive and better able to do their job. The student is often the best judge of what he or she needs to improve in their job. Employees as a whole want to do a good job. They want to improve.

Employees are forced to take classes they may not need or want. Or they take a class and then they may shift to a new role or position and never get a chance to use the information. Then the company deduces that training is a waste of money, time, and productivity. It’s not the fault of the training or the employee. It’s the fault of the company in not managing education and training as part of the overall business process.

So, let’s pull this together. Education and training of employees are seen as costs rather than investments because of the outdated business model that if an employee is not producing something concrete and measurable, they aren’t productive. It’s extremely difficult to measure programmer or even consultant ‘productivity’. Companies don’t invest in something you they can’t quantify and ‘improve’. If it doesn’t have a direct effect on the bottom line, it doesn’t exist or is a cost.

That’s the bad news, and a lot of companies are in that ‘mindset’ (companies don’t have minds). The good news is that there are companies that value education and training and make it a yearly requirement. More importantly, they actually follow through rather than just having this as a hollow promise based on budgets.

Employees who can take training, and training they want or need, even if it’s not directly related to their jobs are going to be happier. They will be more creative. They will be able to have a perspective not tied to their immediate jobs (this can be scary for some companies). They will be able to solve a wider range of problems. They will be more productive.

Sent from Auteureist™

Advertisements

A Need for Code Understandability Metrics

I had an interesting Twitter chat with someone during the PhillyETE conference. One of the major takeaways from for me was that source code is written in order to be read (in addition to being executed.) Humans are going to spend a lot of time reading your code (even if its only you). The code should be written in a way that enhances its understandability. The chat got me thinking.

Testing is a hot topic. Many developers do TDD, BDD, unit testing, integration testing, deployment testing, etc. But when it comes to testing whether or not our code is understandable, we mostly fall back on code reviews. We don’t test the understandability of the code we review.

What does a code review test? I’d argue a code review’s purpose isn’tt to test anything, its purpose is to assess the quality of the code, its functionality for overlooked defects, to share knowledge amongst peers, and its readability.

For the most part code reviews are highly subjective and personal, guided only by experience and the process established to run them. “Readability” is often used interchangeably with “understandability”. A program with no white space is a lot harder to read than a program with white space. That doesn’t make the program any more understandable.

One point that came up in the chat was that whether the code is understandable is dependent on the business and understanding the business processes. It’s domain driven. (Assuming a non-DSL programming environment). I’d argue the domain information is independent of whether or not someone can read the code and easily understand what it does.

Knowing what code does is functional (no pun intended). The domain information is the purpose or reason for the code and function. You need to know how your bank implements a funds transfer, that’s domain information. Understanding that the code takes a value out of one database structure and adds the same value to another database structure is functional and independent of the banking domain.

Understanding why the code does something is different from understanding how it does it. These are two different levels of understanding.

So, why am I focusing on understandability? I’d argue that the greater the understandability of the code, the easier it is to manage, debug, pass on, etc. Read, “easier” as “more efficient” if that helps.

What makes one piece of code more understandable than another? Uncle Bob Martin’s book, Clean Code, is a good place to start. But there is a big problem. How do you quantitatively measure whether a piece of code is more understandable than another? One may argue that itâs highly subjective. I’d argue not. Here is a simple example:

What does this do? +/X>100 This is a real programming language.

What does this do?    for number in X
                                        if number > 100 print(number)
Which one is more understandable? You say that you need to know the language to understand the code. Of course. But I can give both of these examples to random non-programmers on the street and a majority could figure out what the second example does. It’s more understandable. “Well it’s more English-like.” True.

If you’re a c/C++ programmer, what does this do?

main(a,b)char**b;{int c=1,d=c,e=a-d;for(;e;e–)_(e)<_(c)?c=e:_(e)>_(d)?d=e:7;
while(++e<a)printf(“\xe2\x96%c”,129+(**b=8*(_(e)-_(c))/(_(d)-_(c))));}

(this from the Obfuscated C contest.) The understandability is [intentionally] bad even though you may know the language.

We need a way to measure and objectively compare one piece of code against another for understandability. We need metrics. We need tools.

This is an extremely hard problem to solve. It encompasses the language, white space, all of the “clean coder” concepts and others. It is, however, I’d argue independent of domain knowledge.  I believe it’s important.

Any volunteers? Flame on!