How to lose 80.000 SEK by changing phone policy

How much can your company save by enforcing a “business calls only” policy on the phones employees get? What about moving to a cheaper laptop? Or not having free coffee, or…

I will argue that you will lose quite a lot.

The argument at it’s base it simple – When you make things a little bit worse for your employees, they are a little more likely to leave. [1] No one will leave a job because of a new phone policy, or a cancelled x-mas party. But we all have little counters in our head, counting how much we like our jobs. If the counter reaches zero, we will leave. So the person that is annoyed with the open landscape seating, the salary levels and the quality of coffee may just reach zero when you remove the fruit basket.

One company I know of allows their developers to choose any computer when they start. This policy was created in cooperation with HR. Developers are easy to bribe and getting them to stay longer has a value many times higher than the cost of a Macbook over a cheap dell.

But the people making the decisions about new phone policies tend not to look at it that way. So for fun, I did some numbers.

A few assumptions:

•          A standard recruitment cost is around 20% of a yearly salary
•          In Sweden, a reasonable recruitment time is 5 months (2 months searching and 3 months severance period)
•         A company expects an employee to add more value to the company than they get in salary. I’m using the number 5x here. Meaning that for every 100 SEK you are paid, the company expects you to generate 500 SEK of value.
•           It takes time for a new person to get up to speed. I’m going to assume 12 months linear improvement from 0 to 100%.

Based on those assumptions, and picking a randoma salary of 30.000 SEK (Ignoring extra costs) replacing an employee will take 17 months, and during that period the company will have lost 1.57M SEK.[2]

So, if your policy makes it 5% more likely that an employee will leave, your expected loss is 131.000 SEK - per employee. That’s quite a bit of cell phone bills…

But, you say, your numbers are off! “Crappier coffee will not make it 5% more likely”, or “A person only generates 312% of value over their salary” or even “You’re not even doing basic multiplication correctly!”. Perhaps you are right. But what I’m really after is not to show you an exact number, what I’m after is to get you to think about the other side of the equation when doing a silly cost saving. And if you read this far and checked my numbers, at least you have thought about that. So thank you.

[1] Management 3.0 – Jurgen Appelo

[2] From starting recruitment to the new employee is fully performant takes, according to our assumptions, 17 months. During that period we see

Meetings – The scourge of our existence

“Let’s waste five minutes to reward the rational people that decided not to be on time”

(What I hear at the start of too many meetings)

“Meetings never start on time” 83% [1] of all knowledge workers agree with the statement that meetings never, or rarely, start on time. They also state that they do not end on time, and that most of them are pointless. I can tell you how to solve the issue about meetings being pointless, and after I am done I will tell you the optimal length of a piece of string [2], but those topics are more complicated and will have to wait for a later post. But I do have a solution that works for everyone for the timing of meetings. It does not even require a lot of training [3], are you ready? Here goes.

Start your meeting on time!

It really is that simple. At 0900 I make sure that the doors are closed and I start the meeting. If someone is late I don’t make a big deal about it, but I, like the train, wait for no man. Never, ever, say “let’s wait a few…”. Show respect to, and reward the people that are there on time. In my experience it will take one to two meetings until everyone shows up on time. If I am late, which happens albeit rarely, I will apologize for being late when there is a lull in the meeting that started without me. If you want to get points in my book, you will do the same. Be on time most of the times, and say: “I am sorry for being late” when you are late. I don’t need to know why you are late, but I think it shows respect to acknowledge that you are aware and sorry about it.

“I want this meeting to last no more than 3 minutes and I will allow no more than 5”  

(Leo McGarry, voted best Chief of Staff in 2010.)

What about ending on time? It’s almost as simple. Never let a meeting just overflow. When you see that you have 15 minutes of time and an hour of discussion left you need to choose. If you are getting a weeks’ worth of work done for every hour then ask if people are ok with staying another hour and offer to get them coffee. If the meeting is just dragging on, remind people that you will end on the hour and do not let it last one minute longer. Reschedule if you have to, but never let it drag on.

Let’s end with some questions from the audience

Q - What about people who are running from another meeting?

A - Start your meetings at 15 minutes past the hour and run for 45 minutes. Or consider a 15 or 20 minute meeting.

Q – I don’t run the meetings, and the person that does will not start on time.

A – Tell her, respectfully, that you would appreciate if we could start meetings on time.

Q – Why should I care about meetings starting on time?

A – The surface answer is: To avoid wasting time. 12 people waiting 5 minutes is an hour of company time wasted. The deeper answer is that a person being late tells the rest of the team that he does not think the meeting is important. Funnily enough it will also, subconsciously, tell the person being late that the meeting is not that important too [4] .

Q – What about phone meetings?

A – For phone meetings, when dialing in, I allow 5 minutes for technical issues until I hang up. I give my manager up to 7 minutes and his manager and above up to 10 minutes. But every time they use the extra time I respect them just that little bit less. When opening them I allow up to 1 minute of technical issues until I start speaking. Dialing in on time is not rocket science.

Q – Who just joined?

A - My point exactly.

Q - Is this blog post really necessary?

A - I think not. But remember the 82%? For some reason this is hard for organizations. I think it’s considered rude to tell people that they are late. But it’s even ruder to force people to waste their time waiting for someone that is late.

Q – Do you have to use such an arrogant tone in your writing?

A – I’m not trying for arrogant, but I am aware that it may come out that way. Members of my household hate my style of writing. But it amuses me, and in the end that’s why I write. So if it annoys you then I am sorry. Obviously not sorry enough to change, but sorry even so.

[1] I just made that number up from pure air. Sorry. The creation of this article was based on the headline of another article where people complained about meetings not starting on time. But it sounds about right, doesn’t it? More than half, but less than all. We can all agree that many people think so at least. I bet you will read the rest of the foot notes.

[2] 43,7 cm. Most worthwhile problems lack a good “one size fits all” solution, but there are ways of making meetings better, and I may even cover them in another post.

[3] I am offering consulting services in the area of “making meetings start on time”, I charge $300/hour, 40 hours minimum charge.

[4] Pre-Suation, Robert Cialdini, 2016. 

When ever you start a sentence with “I am not a lawyer but…”

Just stop talking. Nothing you say after that point will be any good for you or your company.

These words of wisdom were shared with me by Donald (@DonaldOJDK), and I get constant reminders about how correct they are.

My favorite foot-in-mouth story is a thread with, what I though, were two sales reps that were in conversation with a customer about the BCL. I keep replying “I can not interpret contracts for you since I do not have a law degree”, but they keep asking and asking and asking. Finally, in frustration, I reply, “I am not a lawyer, but it’s perfectly obvious to me that XYZ is the correct interpretation, and I’m sure that your local legal rep will back the obvious interpretation up”. Somewhat happy about closing the conversation that would not stop I go for a coffee. When I come back I have an email from one of the sales reps who, as it turns out, was not a sales rep at all – “I AM the local legal rep, and it’s far from obvious to me…”.

This leads to a note to self – Do not comment on legal matters. It’s surprising how hard that is. That and realizing that I need to learn to live with that fact that there are people on the Internet that are wrong, are difficult things.

But why, people ask, can you not summarize how license X works?

Let me start to answer by showing two examples of code.

Version 1.

printf(“Hello World!”);

Version 2.

String res = new String();

LanguageStuff ls = new LanguageStuff();

res = “World”;

res = “ “ + res;

res = “Hello” + res;

res = res + ls.puncuation(LanguageStuff.EXCLAMATION_MARK);

printf(res);

res = “” // Help with GC

They both work, somewhat. But it’s obvious that one of them is unnecessarily complex, not to mention verbose. If you saw a fellow developer writing Version 2 code you would likely correct him and send him to a beginners coding training.

So as developers we try to write code that is as clear and concise as possible. As long as every case is covered a reasonable rule is – shorter and more readable code is better code.

So why is it that we seem to believe that lawyers always write contracts using Version 2? I think it’s safe to assume that the 10x theory of developers also apply to lawyers and that some of them are brilliant and some of them will be not as great. Same as with developers and just about every other profession.  So when in doubt I always assume that the contract or license is written as short and as clear as possible, while still containing all the parts needed for it to be legally complete. So the reason that I will not try to summarize a license is that I do believe that the person with the law degree that wrote it is a better lawyer than I am. If she could have written it shorter and clearer, I will have to assume that she would have.

That being said, I am still to understand why something is MORE LEGALLY BINDING IF WRITTEN IN ALL CAPS. (YES, I’M LOOKING AT YOU BCL)

Selling a technical debt reduction

“Over time all code transforms from a thing of beauty to unreadable spaghetti code”

 Old proverb

Wikipedia defines Technical Debt as follows

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

We all have an instinctual understanding of what it means, that it’s bad and that we should fix it as quickly as possible. So, why don’t we? The main reason is that our managers will not let us spend time refactoring until we have shipped the release. And when the release is shipped there is no time to refactor since we are now working on the next release and so on. And our debt increases and we spend more and more time working around deficiencies in our code base than we do on creating a better product.

Shipping the next version of the product is important, but over time the company will actually lose time and money by not handling technical debt. So how do you ensure that it will be paid off? A common argument I hear is “but my Manger understands that this must be done, and if he doesn’t then he does not deserve to be a dev. Manager”. Assume that this is true, and your manager understands the need. But he has to defend the schedule slip to his manger that may not understand it quite as well, and he must explain to someone else and so on. That leaves you with two choices. You can stick your head in the sand and say that if the company is not smart enough to understand this then they don’t deserve you. Or you can sell it to your management chain.

Your secret tool is a ROI calculation.

Find out, to the best of your ability, the following data points.

•        How many engineering years are spent on the product per calendar year
•        What percentage of the engineering time is wasted on technical debt
•        If you could spend X, Y or Z (see below) man-months fixing technical debt, what would the waste percentage be then

What is X, Y and Z? It depends on the size of your projects. Y is the number of man months you would suggest as optimal. X is less than Y, let’s say half. Z is more, 50% or double.

Then, armed with this, you create powerpoints stating the following:

Where are we today? How much are we losing, in concrete numbers? Make sure that your estimates are the best you can come up with, and write down in speaker’s notes how you came up with them. The most important delivery of the presentation will not be you presenting to your boss, it will be your bosses boss presenting to his boss and he will need your notes.

Given three scenarios, where could we be? Be realistic. In this example I acknowledge that even with infinite time we would never reach 0% lost.

Summarize the findings. Include how long it will take to make up for lost time, as well as what the savings over a longer time, in this case 5 years, will be.

“Cost” is number of Engineering Years spent in the refactoring project.

“Savings Per Year” is how many Engineering Years will be saved per Calendar Year, in the form of reduced waste.

“ROI” is the number of months it will take until the time spent on refactoring will have been gained back by savings from having refactored. (In the example below – Spending 2 Engineering Years on a project that results in 3 EY/calendar year savings will have a break-even point

Great - You are almost done. Now make sure that the speaker’s notes have all the information that someone you never met needs to be able to perform your presentation.

Best Practices

Show your work

As you well know, the numbers on “percentage lost due to technical debt” and the estimate on how much this will be improved are estimates and guesses. For almost all cases it will be impossible to get perfect data, so the estimates is the best there is. Show your reasoning behind the estimates and put them in the speaker’s notes. And make sure that you really make your best guesses, not guesses that support what you want to do. A loss of trust here will be catastrophic.

The 90/10 rule

If your loss due to technical debt is less than 10% then it’s likely not worth the bother to try to fix. While 10% sounds like a lot, consider two things. One – It will never be 0% unless it’s a green field project. Two – If you are like me and everyone I know, you will tend to believe that the loss is little bit higher than it actually is. The exceptions are if it’s extremely well defined, like time spent waiting on testing to complete two times per day compared to time invested in a continuous integration system.

Keep it Short

Long refactoring projects are scary. Your chances of getting permission to do them increases a lot if you can keep them short. 3 to 6 months is a good rule of thumb based on the size of your projects. And having 1-2 engineers, or max 10% on the project also helps sell it.

No skunkworks

A tempting solution is to just hide that you are doing refactoring from your management and just do what has to be done. This is a terrible solution, because when you get found out, and you will, there will be no trust left between you and your manager. (I’ll comment further on a related topic in another post, in 2019 if I keep this pace up)

Closing words

Selling a refactoring project need not be hard. Just show why it will save time/money and understand that everyone involved needs to be able to cover their… err… needs to be able to justify the time expenditure on something that is not driving features.

Get an early peek at JDK 7

We have a pre-release of JDK 7 available for download.

I would encourage anyone that is interested in Java to download and try it out.
(Look here for hints about what you should try)

Let us know what you think, and if any bugs managed to slip through our QA.

What would you have wanted someone to tell you when you were in high-school?

First, I´m very aware that its been too long since I posted anything. Technically, living in internet speed, this blog is dead. To quote another blog, "its complicated". But, never mind that now.

I recently got an email from someone that wanted a speaker at our Swedish sales office. The audience is a high school class. They have studied operating systems, local networks and around 200 hours of Java. The requestor also had some idea of what we should talk about, but the chance to tell a high school class what I wished I knew when I was that age is more interesting than what he wanted. (I normally give, roughly, [well ok, thats not true, but lets pretend...] the presentation that people ask for, but he ticked me off, see next paragraph)

As I was letting the email stew a bit in my inbox, he calls me. Tells me a bit about the event and what he is expecting. So far so good. He then goes on about how he wants someone representative from our office. Makes sense. "They tell me you have someone named Tuva working there". Hold a minute. Tuva is one of my colleagues and very good at what she does. But she is a woman in an IT company. A product manager to boot. Around 10% of our dev office are women. Don't tell me you want a woman presenting because they are "representative". They are a minority. I wish it wasn't so, but don't pretend that they aren't. If you tell me "we want a woman to represent because we want to get more women into IT" I will support you 100%. But don't try to BS me, or the audience for that matter.

Now, me and Tuva will do the presentation, but we will (most likely) cover the issue of women in IT without pretending its all sunshine and ponies. Seems like this is a sensitive topic for me, since this was not the indented focus for the post.

The intended focus for the post is "What would you have wanted someone to tell you when you were in high-school". I started thinking about it one the subway home, and it was exciting enough that I turned off my Kindle and just sat staring, thinking about what I would like to say/wanted to have known.

So, just a short brain dump

What are the career paths in IT? (Developer, Tester, Project Manager, Architect, Product Manager, IT Manager...)

What are the skill sets needed for those paths? (The personal traits for a Developer and Project Manager are very different. Some people have both, but they are rare. For a Product Manager, the ability to understand and communicate is more valuable than skill as a developer. Having an expected career path from developer to manager is stupid, the skill sets are different. Some have both, but lets create a good career for those that want to write code, not lead...)

Common myths

- You start at a low salary, and then work yourself up in the company (No, you start low, work your dog year(s) and then change job and get your raise. Your yearly raise is percentage based. Low + 10% is still low)

Bold statements

- There are no old programmers (for some value of 'no'. What happens to us as we grow up? Is this changing?)

- Evolution of programming languages will be faster than you can keep up with (but thats ok.)

- I can learn a new programming language in a week (true)

- It takes a year to become proficient in a language (true as well)

- First learn to do your thing without tools and IDEs, but dont suffer for too long.

- Pick one editor, IDE and language and become an expert in them. (If you have to change later on it's not the end of the world)

- You need to know how to do SELECT and INSERT in SQL, no matter who you are

- Think what you wish of HTML, but you need to know some of it

What did I learn in school that is most useful for me now?

- err...

Writing that was a too easy. I could go on for a few pages more, but the main reason for this post is to ask you what you would want to have known in high-school? Let me know in the comments. Just a note - I have bad experience with Spam on blogs, so I have to approve all comments. My promise to you is that unless you are spamming I will approve it. If, for some strange reason, you post a comment that isn't spam but I still don't want it posted, I will make a post explaining that I censored you and why.

What have you done for me lately?

Quite recently the following message went out to our Java SE Licensees:

Upcoming changes in Java SE HotSpot build process Dear Java SE Licensee, November 05, 2010 Oracle would like to inform you that we are planning on eliminating the includeDB mechanism from the HotSpot build process starting from JDK7 and upcoming updates of the JDK 6. The includeDB mechanism was in the HotSpot sources for a long time serving the purpose of generation of necessary header files include list for each source file at the compilation time. It was also used for generation of the precompiled headers that significantly reduce compilation times for Visual C and gcc compilers. It consisted of two parts: the MakeDeps tool written in java and plain-text database files with recorded header files dependencies. This approach became a maintenance issue and it also creates unnecessary difficulties for using modern IDEs for code development. The dynamically generated list of header files for precompilation will now be replaced with a static one and all include files will be explicitly listed at the top of each source file. This activity is known as CR 6989984. A separate task known as CR6981484 will result in an update of the development launcher. The current development headless launcher known as gamma launcher has a number of limitations and is not existent on Windows. The new launcher called fusion will be present on all supported platforms and will have a new switch for launch inside a debugger. The current plan is to implement the new launcher as a shell scripts that wraps around the existing gamma launcher on Solaris and Linux and create a new separate executable for the Windows OS family. Switching to the standard include model will enhance code maintainability. We do not expect this will be affecting Java SE licensees port in any major way, but we would like to give you an advanced notice so that you can plan your upcoming release accordingly. If you have any questions or concerns, please contact your Java Licensee Engineering representative. Thank you and best regards, Java Licensee Engineering Oracle Corporation

That is obviously one way of saying it (whatever _it_ is). If someone tweeted the first line, and someone else made an article based on that tweet, the article would read.

Oracle removes free Database from Java

Puppies missing from orphanage

But what does it really mean?

My own headline would be

OpenJDK now 300% easier to compile

(Full disclaimer: I just made the 300% up. I don’t have any independent research on the issue. And if there was, I expect it would be more than 300%.)

IncludeDB/MakeDeps was a non standard way of handling C++ header files. Back in the days of yore it solved a number of problems, but in a world with modern IDEs it’s more of a hindrance. We are now moving to using normal header files. This will allow users to use an IDE with a minimum amount of tweaking (as opposed to the previous maximum amount) and will seriously lower the bar for new developers that want to work with OpenJDK.

So, if you want to work on OpenJDK this is good for you. If you want others to work on OpenJDK this is also good for you. You’re welcome.

(We have done a few more things for you, but that will be a matter of separate posts)

/T