Strong Opinions

As Code Cop I meet a lot of developers and I have to tell some of them that their code is crap and that they need to drive down their technical debt. Others need to test more, maybe start doing TDD. There are a few who would not listen. Some of them are even proud of stubbornly not listening, they say that they have strong opinions about the topic. They do not seem interested in in another view on their code or design? Why is that? I have some ideas.

Dunning Kruger Effect
The Dunning Kruger Effect is a cognitive bias in which people of low ability have illusory superiority and mistakenly assess their cognitive ability as greater than it is. In other words, beginners believe themselves senior and think that they know better. There is no need to listen to an outsider.

I know this effect myself: When I learnt my first programming language(s), as soon as I could write a few lines of code, I felt invincible. (I thought that) I could do everything. I ruled. I knew how to do it and I knew I was right and that there was no other way to do it properly. Today, after writing code for 20 years in more than 25 languages, I do not feel like that any more. Sometimes I would like to go back to my state of mind of the late nineties and I try to look at new languages like a child - with a beginner's mind - but I know too much details. I know there will be nasty details, even for that newest and hottest languages of today.

Expert Beginner
An expert beginner has quickly reached (what looks like) expert status. He or she voluntarily ceases to improve because of a belief that expert status has been reached and thus further improvement is not possible. (I recommend reading the whole series of Erik Dietrich, How Developers Stop Learning: Rise of the Expert Beginner and further posts of his series.) Expert beginners make up defending arguments because they are the experts.

I have met some of these. I vividly remember two senior developers who had been with one of my clients for more than 16 years. They were opposing me on everything I said. Sure they had a superior knowledge of the application they had built and maintained for so many years, and they knew the domain they were working in pretty well. I am sure they were adding value to the product. They both were strong influencers. As soon as they would speak their mind, all other team members would just agree. But, but, but... Sigh. They were still using Ant, did not know Maven, did not write unit tests, did not care for clean code and so on - they made me very unhappy.

Quadrants of Knowledge
The quadrants of knowledge seem connected to my previous points. The four quadrants are

1. Known Knowns: What you know that you know
2. Unknown Knowns: What you do not know that you know
3. Known Unknowns: What you know that you do not know
4. Unknown Unknowns: What you do not know that you do not know

When we advance our career in software delivery, we learn: We collect concrete knowledge (quadrant 1), we gain experience which allows us to have gut feelings about some things (maybe quadrant 2) and we hear about things that we have no idea about (quadrant 3). There are gazillion things in software that I have no idea of: ANTLR, APL, AWS, Category Theory, Distributed Computing, Elm, Gradle, Guava, Haskell, HBase, J2EE, Kubernetes, Mongo DB, Networking, Node.JS, Prolog, Security - these are just the first few that come to my mind. It is easier to list things which I do not know in areas that I do know. I have been Java developer for 15 years and there are so many things in the Java ecosystem which I have no clue about. On the other hand there are not many things I can say about C#, because I only know it little.

So the more we learn, the more we know that we do not know, increasing our Known Unknowns (quadrant 3). The philosopher Confucius (551–479 BC) even said, Real knowledge is to know the extent of one's ignorance. Like the Dunning Kruger Effect, beginners have no idea about the vast size of Known Unknowns quadrant and do not expect surprises or potential improvements.

Strong Opinions, Weakly Held
The ideas of the Dunning Kruger Effect, Expert Beginners and Known Unknowns offer some explanation why some junior developers are not open for discussions. I have also met senior and expert level developers who are the same. When attending Software Crafting unconferences, e.g. SoCraTes, attendees are eager to learn and open for discussion. After all, that is the idea of unconferences, right? Still, many of them have strong opinions about almost everything, e.g. Spring Boot is cool. No, Spring Boot is hell. ;-) Different from beginners, all of them know the problems of strong opinions and claim that they only hold onto them weakly.

Weakly Held, what is that supposed to mean? Isaac Morehouse explains in These Four Words Will Help You ‘Hold Strong Opinions Weakly': You act as if they [your opinions] are true unless and until it is proven they are not. Maybe people like strong opinions because they give them the power of definiteness. Choices are much easier and life is more predictable with definiteness and absolutes. Holding opinions weakly also gives the power of openness. This sounds hard: Basing one's actions on some definite "truths" and re-evaluating these truths whenever they are challenged. Seems like a difficult balancing act, if not a contradiction. For sure that state of mind is not easy to get into. I still need to see someone with strong opinion - weakly held or not - to change his or her mind,

Rant
When I started this article, it was supposed to be a rant. As usual, writing down my thoughts helped me to structure the material in a better way. (I consider writing an act of learning.) So where is the rant? Here it is:

Person with strong opinion == arsehole who does not want to listen.

That is a bit harsh, I agree. Obviously beginners need to listen more and due to Known Unknowns I expect experienced and expert developers to be open to discussion on any topic at any time. The strong opinion itself is not the problem, but the resulting behaviour, especially if strong opinion is used as warning or justification of some sort. I witness strong opinion mainly as excuse to not discuss or challenge existing views.

What about me?
Of course I had strong opinions during my professional life. I did not earn the nick name of Code Cop for nothing. Someone even called me Code Nazi. And my opinions were definitely not weakly held. I like absolutes. (Now I see - as I just learned above - the power of definiteness.) I guess I still have some strong opinions, and they are not just opinions, they are dogma: a system of principles proclaimed as unquestionable.

I have changed and it seems that the Code Cop is getting soft. ;-) The extended experience and discussions have weakened my definiteness. There is always some special case, the almighty it depends. And since I am working with people, and try to help them, I am more compassionate. I understand their problems, the difficulty to get time for quality and the pain of legacy code. Sometimes I catch myself not recommending what I believe the technically best course of action because it will be a lot of unpleasant, hard work for the team. No, that is too soft. If they made a mess, they have to fix it. Time to fall back on dogma. (Sound of firing cannons in the background ;-) All the time these balancing acts...

This Is Madness

Two months ago my time with Big Blue ended. While preparing for my Journeyman tour next month, I sorted out my drafts of blog posts and rediscovered some notes concerning my last assignment in the company. It was a particularly crazy time and I only wrote about it to clear my mind. Nevertheless, such gems need to be shared. As usual all my writing is fictional and does not resemble any real people or companies.

For my latest assignment I joined another team. I was happy at first because I worked with a new prototype, which was a nice change from my previous waterfall project. The team was led by a Distinguished Engineer, so my expectations were high. But soon the forces of madness showed.

Roll Your Own
First I noticed that one developer had created his own in-memory document store to support OLAP style operations, mainly pre-aggregated sums. I was not sure why he had done that, he had not checked existing third-party products before, but I guess creating your own database is a fun project to play with. Unfortunately many concepts where missing and the provided generality was not needed. (Note: One Does Not Simply create his or her own database system during a development project.) As a new member I did not want to question him during my first weeks and just accepted it. Later when he wanted to add some features, he rewrote the whole thing from scratch during a weekend, dropping at least one month worth of my additions. I was not amused.

Web or Desktop Application?
The project was under active development for almost a year and the business stake holders had still not decided if they wanted a web or a standalone application. The core developers were used to Eclipse/RCP, so they had created a server-client application prototype. When the business was finally ready to decide, the whole team spent two days creating estimates for both variants. "Surprisingly" porting the already existing desktop client to the web was rejected as being more expensive. I guess the business did not really care. (Note: Architecture decisions need to be made early in the project.)

Upload a File
Users needed to upload a large file to the server which would take several minutes. It needed to be extra reliable (but the exact term of "extra" was never defined). So the whole team met online to discuss the issue. One developer had the idea to use messaging for the upload because "messaging is usually reliable" and the company's flagship JMS product was extra reliable. I could not believe it - WTF? The client would still have to upload the file to the server to put it into the message queue. Further messaging is not designed to work with huge files. I begged the lead developer not to introduce a new component only to transfer a several MB file from the servlet layer to the service layer. At this time I started sending emails with "Madness? No this is reliaaaaaaable".

From Prototype to Production Over Night
The project had started as research prototype with the goal to experiment and compare different algorithms. Some of the numbers did not make sense and were being discussed and changed by the business people every day. Suddenly things changed, the whole project became production software and a deadline came up. The deadline was - of course - completely unrealistic but nobody told the business. Further more, there was a strict protocol for production applications in the company which needed many documents and formal reviews. Creating these artefacts delayed the deadline, too.

The Grand Finale
For all this bureaucracy, a young developer was brought in as architect. He did most of the necessary paper work which really helped but then things got nasty. He introduced code reviews - which is a good idea in general - but his findings were useless. First he forced us to use a large JavaDoc template which introduced much noise into our classes and then he demanded that every method would log its entry and its exit. My heart sank, but fortunately my twitter followers gave me permission to ignore his rules ;-)

Again this is not much more than a rant, but it is also a true story. Some of my friends enjoy reading rants, maybe my stories reassure them that one should not work for large corporations.

Where is the Quality?

I am professional Java developer since almost 14 years. I have been coding for education, fun and profit for 27 years and three months now. I bought my first book on how to program BASIC for the Commodore 64 in 1986, even before I got the computer itself. I have been enthusiastic about all this since then and never stopped pushing forward. But I am depressed. Maybe I get depressed easily, as once after a particular bad gig I had to take an antidepressant for more than a year. Fortunately no burn-out this time - I am just fed up. Time for a rant ;-)

The current state of the IT industry makes me unhappy. That is nothing new and maybe my last employer is a particular bad example, but I do not think so. I have been with some companies during my career and talked to developers working on different projects, and usually I hear the same story: Deadline first, crazy rush, get the shit out of the door, repeat. I am the Code Cop, I try to keep things together, clean them up, whip them into shape. But I am wasting my time. My work has no meaning. I am just one but "they" are legion. Recently I got really angry when being confronted with bad code. How do you dare to deliver such crap to my production code base. This is all a big joke.

Some developers have no idea about object orientation, encapsulation or how to design a class at all. The senior developers know their business and applications well, still some of them are unable to create a reasonable design or model classes with a single responsibility. This does not only apply to off-shoring, but to local teams as well. Managers and architects are talking about all aspects of the development cycle but the actual creation of the core asset, the executable code. Development of code is seen as a commodity, unimportant work, just fill in the gaps.

Dark Future
Last month I was invited to a small panel discussion. Together with a test automation expert and an user interface specialist, we were discussing with the audience about the future of software development. The opening question was for our advice for students of higher technical education. Where the testing and user interface people predict a bright future, I have a darker vision. I would not advise anybody who is passionate to start working in today's mainstream IT industry. Software is growing more and more complex and changing it takes longer and longer. At the same time the cost pressure increases. Current trends like Water-Scrum-Fall try to fix these problems with a process. The real issue is the bad quality of our code. We have accumulated a massive amount of technical debt. The same is true for testing. Yes, we plan for unit tests during development, but then need to finish the requirement first and skip the tests. In the end we get some UI test automation, delivered by an outsourced testing team. Hello software testing ice-cream cone.

Escape?
I get many mails from head hunters looking for Java developers. But their work is as broken as ours. I am sure, if they would just read one post of my blog they would not send me information about an open position for a junior developer who is supposed to add buttons to a web application. Some head hunters are even specialized in IT personnel but seem to be as (un-)skilled in their work as most of us. From my experience they just do not care, else they would not send me letters with a wrong name in the salutation. Anyway, all advertisements for job vacancies I have seen so far were flat and did not say anything about what to expect. I am not excited.

I believe that the Software Craftsmanship movement was born to address these issues. But Austria is a small country and I am not aware that there are companies like 8th Light around. Still I know of many passionate developers and would like to hear about companies, where all members of the development team are craftsmen. It will definitely be a small company, at least a small development team hiding somewhere. So please stop hiding and come outside, I am looking for you! (I really hope you exist ;-)

Waterfall and Requirements

We are doing Waterfall. "They" want it to be called Agile using Scrum, but it really is Waterfall. We have nine month release cycles including two months requirements gathering followed by four months development and three months of testing and defect fixing. Before we took over the project it had no process at all, so it is OK now, at least it follows some process. Waterfall is not that bad after all ;-) Currently we are at the end of the development phase and our last sprint will end next Thursday.

Some time ago, the customer suddenly found additional budget and decided to have another requirement implemented. (I have no idea how big organizations can suddenly find more budget, maybe under the mattress of the CEO?) We (the development team) were already booked up with requirements, so he brought in some special people from "Lab X". Lab X is located in off-shoring country Y, but that is not the point here, so let's just assume he found them under a stone. People from lab X had no opportunity to get to know our application, which is eally complex, a Big Ball of Mud with cryptic use cases. Finding your way around our one million lines code base usually takes more than six months for experienced developers.

I had heard about that additional requirement some time ago, but was busy and did not pay much attention. Recently things went bad. The senior developer from Lab X left the company or got rotated to another project, which had already happened before (in another release cycle - another story). I heard that it is common for developers to switch companies in country Y if they get a better offer from a competitor. One or two new junior developers were brought in to continue his work. From what I saw of their code, I do not think they deserve the word "junior" at all: someJavaString == "" is a clear sign that someone has no idea how Java works nor did he or she test the code. I do not blame them, it is not their fault. If you cannot find experienced developers, you have to hire new ones and train them, coach them and let them grow. Maybe they are experienced in another language, I do not know. I just know to expect these things from cheap labour service centres of country Y, where nothing is a problem and everything will be dealt with. "No problem Sir, it will be handled. Everything is OK now."

Right from the beginning two members of our team were asked to team up with the lab to help integrating their code into our product, which - of course - would not need much time. As far as I know they already worked five times as much on the integration as estimated and one went so far to implement parts of the solution on his own time and give it to the lab people to use it instead of their crap, which had not worked. I believe that he should not do that, but I respect my team member to have his reasons, so let him work double shifts if he feels like.

Early on the cycle, some executive or a project manager had signed a document to approve the inclusion of this new feature, so we have no option to escape this mess. I was told that the project manager keeps reminding the customer that his actions have been proven to be problematic but from what I know, the customer's representative is a true alpha-being and will not listen to anything he does not like. (I once had a phone call with a similar executive where I wanted to discuss a certain problem, but during the one hour call I was unable to say a single sentence, so obviously there was no problem and no actions were taken. I really need to improve my communication skills ;-)

So everybody works hard and the current release will be a success including the extra feature, the customer will be happy and nobody will learn anything. As soon as the new feature will be in production, the resources from lab X will vanish and we will be stuck in the quicksand a bit deeper. I hope that the world ends this Xmas as predicted by the Maya calendar and all this ends.

The Diaries Continue

My employer, or to be more specific the department I am working for, is hiring senior Java developers. This is a rare opportunity as usually IT related jobs move from high-wage economies to places where wages are lower. So people keep asking me how am I doing. Here is an update of my diaries. As usual all my writing is fictional and has no resemblance to any real people or companies.

Finding a Friend
In August I made sort-of a friend. He is from another team and our teams are not related, but we share the same version control repository. By accident I saw some crazy things in his changes so I mailed him. After a nice discussion he started reviewing my changes and sent me an email whenever he spotted something that looked suspicious. In the same way I have annoyed people all over my own team with their code, so no one hesitates to send me a note whenever I misspell something. Sweet Revenge Huh.

Consequences of Diaries
A few days after I had published my first diary, my boss approached me and asked me about it. I was frightened. Had I gone too far and pissed someone off? I checked the blog post several times to make sure it was neither aggressive nor diminishing. My fear was unfounded. As I had been wearing my own shirts with my URL code-cop.org on it, a colleague had visited my blog and read it. He was concerned because my writing seemed depressed. So my manager took me aside to confirm that I was still the right person for the job and that he had no doubts about me. It was good to know that someone cared about me, especially at the beginning of a new job.

How to Order a Book
After buying a book about some technology being used in the current project I asked my manager for a refund. I used to ask for a refund of book expenses. It was not about the money but more about a gesture of my manager that he or she appreciated and supported me reading technical books on my personal time. Unfortunately, during most of my jobs, I was not supported and my requests were rejected with ridiculous excuses. So eventually I stopped asking. Refreshed by the new job I did ask my new manager without expecting much. Again he surprised me. First he checked how to fill the form for a refund, then he helped me, in person, to fill it. Later he kept me updated about the state of the approval process without even me asking. That made me feel supported like never before.

Error Handling
It turned out that our application had serious problems in its error handling. Pieces of code like

catch (Throwable t) {
   throw new Error(t.getMessage());
}

or my favourite code snippet to throw all exceptions,

for (Throwable exception : exceptionList) {
   throw exception;
}

were not uncommon. And I am not talking about the 636 empty catch blocks placed throughout the application.

Strong Language
Nevertheless things went well. The crappy code did not improve on its own but we grew a team and started cleaning up the mess. I kept finding awful heresies of code which had been freshly perpetrated and did not hesitate to point them out. Once a particular change made be very unhappy - well not only unhappy, but it made me sick. It contained everything you would not like to see in your code, for example strange boolean expressions like if (isChanged == true) instead of if (isChanged), useless field names like _dpL, magic numbers, large amounts of commented code, long lines mindlessly formatted and even more problems. I spent an entire hour summing up the problems and proposing ways to fix them. I contained myself but I might not have been particularly polite. Afterwards I had a chat with the developer to make sure that he was neither insulted nor angry with me and everything looked fine. But the next day my manager showed me an email, he received from the developer complaining about my strong language that had made him feel uncomfortable. (Strong language is a markedly or unwarrantedly forcible or vehement manner of expression or choice of words.) I admit that I am direct and I understand that do not and wrong might be considered strong language by certain people, but I have also strong opinions about what you just do not do in your code and when some functionality is in the wrong place. He should consider himself lucky that I did not follow Alberto Savoia's Management Approach.

CV Wizard
We are a service organization and every employee is asked to enter his or her curriculum vitae into an internal database. When a proposal for a customer is prepared, sales people browse this database and choose suitable people for the project. Although I was on an active project the reminder emails of the CV wizard kept pestering me. After a month I gave in and started to fill in my data. It looked easy but was not. For each passed project I had to figure out my role, my tasks, responsibilities, contributions and accomplishments. "I created code, it was clean and worked" did not quite fulfil these requirements. Additionally I had to choose my words carefully as the CV was supposed to help sales people and should communicate "I deliver client value" at least in every third sentence. It took me 11 hours to finish my CV but in the end I liked the result. I have never known I did so many great things ;-)

Incoming Changes
I used to review incoming changes. I did not do formal reviews, just browsed through the changes before accepting them, read the descriptions and had a look at the differences if I felt like it. Some day in November I stopped doing that as it was pointless. Usually I managed to read three or four changes before I fired up my email client and started writing about the given architecture, coupling, separation of concerns or similar things. It just took too much time, therefore I could not afford to spend several hours each day on informal code reviews. So I had to "trust" my colleagues instead.

Learning Plans
To get to know the company, new hires were supposed to work through special learning plans each consisting of several hours online presentations about various topics related to the company's policies, workplace habits and offerings. End of November I finished the first one. Finally I started getting an idea what the company was all about.

Goodbye Eclipse
In the middle of December I wrote my last piece of code. Caring about the overall product, development process and architecture I (was) moved more and more into backlog definition, sprint planning, setting up the development infrastructure, code reviews and acting as team lead. I spent most of my time attending meetings and writing emails. It makes me unhappy.

Desk Sharing
I do not like desk sharing. Setting up my keyboard and aligning my monitor each day is just a waste of time. Further most of the screens are so dirty that I need two cleaning pads to wipe them. It looks like I am the only person caring for clean screens in my area of the building. With the beginning of January things got worse. The company started a big project and lots of new people were joining. The office got crowded and - in the end - was running out of space. Some colleagues started working from home several days a week. While working from home may be desirable under certain circumstances, it was not helping us at all. Informal communication stopped happening and the team started falling apart. As a late worker it made my life especially difficult. When I arrived at the office most desks were already occupied. There was no way I could sit near my team (or at least what was left of it). Well, almost no way. I chose to sit on a coffee table in a break area next to my team for several weeks. That situation really annoyed me. Since 2005 I have been working with two screens all the time, even at home, and suddenly I was downgraded to using a small Laptop screen and no proper place to sit.

No Time to Write Unit Tests
As I said before, there were several teams developing a family of applications and sharing the same version control repository. There was no separation of these applications and the teams were connected and somehow depending on one another. I was always happy to spread the idea of clean code and did not stop inside my team. A colleague from a smaller, recently introduced application showed interest in raising the quality of his work. He asked me for help to introduce unit tests into his development work and I was more than eager to help him. He is smart and understands the concepts. Short after that he started writing useful tests. Unfortunately things did not go well and in the end he was forced by his team lead to abandon writing unit tests. Of course the team lead did not tell him to stop writing tests. He just asked my colleague to get more done and that he should not even implement the requirements completely, just implement the happy path of as many features as possible. That made me angry and depressed at the same time.

Resource Action
Last month I overheard my manager talking about a serious situation in the company's US branch. It was about some 'resource action'. I did not understand what it was about and did not care, US was far away. At least it was far away until I opened the intra-net page the next day. I guy that I knew was affected by the resource action (read layoff) and had been axed. I was shocked because Robi B. was no ordinary employee, rather one of the more dedicated ones. We did not share any work but I kept noticing his posts and comments all over the place. Well, probably not all over the place, as "this place" was huge, but at least in the areas that mattered to me. Recognizing him as a community builder and enthusiastic individual, I got in touch. Robi believed in innovation and organized Hackday beside his regular work. (Hackday was a community of people engaged in creating new tools and brainstorming great ideas about how to make their work lives better. For more information follow @hackday.) Robi had been with the company for almost 15 years and had started several innovative projects.

Diaries of a New Employment

I have got a new job. My last employer, sort of a startup, went bankrupt. That's particularly sad, because they offered "Research Days". Similar to Google Friday, you were allowed to work on a random topic one day in a month. One day is not much, still it's so much more than other companies offer. The new one is big. After some nasty times at big companies, I'm not sure if big is good for me, but still I have to try.

(Sort of a) Diary
Since first of July I've been working there. Some friends asked me how am I doing. So here is my diary. It's biased because I'm too strict. To be fair - everything looks good. I'm not dying from excitement, but it's ok. I have to get used to it.

• Day 1 - Shocked. It's my first day and I'm already totally shocked. A senior team member commits production code containing System.out.println because he doesn't bother to remove them. Later another team member doesn't know Eclipse's "Compare With/Each Other" function. I feel like running away.
  
  
• Day 4 - Déjà vu. I'm the new guy in the team and the new guy is supposed to update the development setup documentation.
  
  
• Day 6 - First Blood. Out of curiosity I take a brief look at the existing code base: There are more than 7000 classes with about 600000 non commenting source statements. There is all the classic legacy stuff you would expect to be hidden in such a large code base, e.g. methods containing up to 700 lines, many empty catch blocks and much more. But my favourite findings are the 60 Java source files which have been commented out completely. (I didn't know the Java compiler allowed empty files without any class declaration.)
  
  
• Day 8 - Deadlock. I'm supposed to add information about myself to the internal directory. To edit my entry, I need to fill in a valid phone extension, which I don't have yet. So I try to get one but the phone extension registry would not give me one because my directory entry is incomplete.
  
  
• Day 11. For two hours I'm unable to start my e-mail client. I'm trying all kind of workarounds but it just wouldn't work. I'm getting desperate. In the end it turns out that there is an internal application to clean up and restart the mail client which finally solves my problem.
  
  
• Day 12. Today I saw the first person wearing shorts in the office. I was already getting stressed by being the only one wearing t-shirts and shorts among many people wearing suit.
  
  
• Day 14 - Hope. We are preparing a list of refactorings that would improve maintainability of the code. I stay quiet because I'm the new one and don't have all the information. I'm glad when another team member proposes what I wanted to say. There is hope.
  
  
• Day 15. The project manager wants to give me responsibilty for the continuous integration build. I cringe because setting up and maintaining the build is cumbersome and boring. Fortunately my manager objects that "there are other important things for Peter to do". +1 for saving me.
  
  
• Day 18 - Public Relations. I know it's a waste of time, but I'm stubborn and ask the person responsible for PR/communications about the mode and support for publishing and presenting. I never got an answer.
  
  
• Day 20 - Coder from Hell. A senior colleague does not care for compiler warnings because "he knows what he is doing". Well he should know better, especially as we are tasked to clean up some legacy mess that exists because of people like him. Anyway he doesn't give a shit about clean code. I haven't met such a kind of a developer before.
  
  
• Day 22 - Print a Page. I need to print a page. This is usually not a problem. I install the printer driver, print the page, go to the machine and find that the device is out of order. Then a colleague tells me that it's broken all the time. Where is the next printer? So I find the printer on another floor, install, print, go there and find that the room containing the printer is locked. Ok, I repeat the whole schema with the printer of another floor, go there - but it's not "there". I can't find this bloody printer. I repeat with the printer on yet another floor, go there - and finally I'm able to collect my printout.
  
  
• Day 28 - Long Line. I just found a single line of code containing 2881 characters. Yes, a single line. That's by far the longest line I have ever seen and it's even way beyond any long lines recorded by fellow craftsmen.

The Lie

<fiction>
Let's start with a little story about an enthusiastic software developer called Bruno. The story begins with an interesting job offer: A well known company is searching for an experienced developers to enlarge an existing team due to an increased business demand. The company does software since more than 40 years and scores reasonable at the Joel Test.

The Interview
The company is looking for top developers, a difficult coding exam during the interview is making sure to weed out the less skilled ones. The exam contains of a full range of Java traps: Beginner mistakes, try-finally idioms, generics and even some Java Puzzlers.

Bruno is one of the best. He finishes the exam in no time and scores well. Two small mistakes he makes just manage to curb his enthusiasm. The interview goes on with questions about common Java frameworks, ORMs etc. For the first time since long he feels challenged and invigorated by the exam's questions and the interview. He asks his usual questions any serious developer should ask about a future workplace, e.g.: How complete is the build? How does the code look like? Are there many singletons? (Because he just hates singletons. They are pure evil.) He gets some reasonable answers and accepts the offer in the end. The world seems like a happy place.

A Happy Place?
What look's like the beginning of a happy story is in fact its end. As soon as he starts working for the company he discovers that the interviewers had been lying about some things. Maybe they didn't know (but ThreadLocals are still singletons, aren't they). Maybe they were in some state of wishful thinking, confusing planned things with reality. Maybe there were other reasons nevertheless Bruno is disappointed.

Even worse Bruno's work does not reflect the skill level suggested by the interview: Java 4, JDBC statement driven persistence, no challenges, no problems to solve. All he has to do is to make already deeply nested ifs a bit deeper to find a place for more business logic. Bigger changes are discouraged due to the fear of breaking anything. (This might be the case for most modern business applications based on legacy code. Their business logic winds itself in endless, cascading ifs through all layers of the code. Or when did you need to come up with a more complex algorithm than iteration the last time?)

Bruno doesn't want to quit. Running away just doesn't just feel right. He has high expectations. But as the relation with his boss gets worse he gives up and quits. Everybody including himself agree that he wasn't the proper guy for the job in the first place. Hmm. How could that happen?
</fiction>

The Essence of the Lie
It has been two years since I first realised "the lie" as what it is. There were times when it really bothered me, but most likely it's just another thing to consider when looking for a job. It's well known that there are at least two kinds of software people. Some call them developers vs. programmers, smart vs. non smart, craftsmen vs. hackers, experts vs. journey men, professionals vs. duct tape programmers, coders vs. "code monkeys", etc. The essence of "the lie" is that some companies looking for the first kind are in fact in need of the second.

This is not a rant against these second kind of programmers. There's nothing wrong with them. (Note: There is a negative undercurrent in duct tape programmer or code monkey but that's most likely due to the arrogance of us craftsmen. So I will stick with the term plain programmer.) For certain problems in certain environments the plain programmer is simply the better choice.

Anatomy of a Plain Programmer
Now I'll try to list some virtues of a plain programmer :-)

• There is no need for a plain programmer to know his or her IDE well, he just has to know the debugger, because that's the tool he will use most of the time to poke in the legacy code.
• And he doesn't need to know any advanced language features and God forbid he must not use them. (His peers will be confused, so he should better stay with the stuff everybody knows.) So for example there is no need to know concurrency. (Note: I'm not joking, I witnessed my boss questioning the usefulness of an internal training about Java concurrency features.)
• It's desirable that he doesn't think too much about his work, better cascade another if and change existing code as little as possible then mess with the underlying design. (Refactorings and design changes almost always spoil dead lines, esp. when they were ridiculous in the first place.)
• He has no ambitions and does not feel the need to change already messed up processes.
• And last but not least he has to have a high capacity for suffering. He will need it.

In my experience it's more about the environment enforcing or at least encouraging these behaviours than someone just wanting to be like that. Less aspiring people with a high tolerance to discouragement just happen to endure it longer.

When Hiring
So next time you need a programmer make sure you know what kind you need. Don't lie to yourself. Don't give in to wishful thinking. It might not be comfortable for you but your project/organisation might be a mess. If you are in such a situation that you need a plain programmer, hiring an expert developer is just a mistake. You don't need a rock star programmer to churn out another business rule. Don't ruin another craftsman's life by sending him into a battle he can't win.

Digressions

Two months ago I got a brand new Android phone from my employer. I asked for it to play around and get used to Android development and bingo - it was here :-) This is a major event compared to my prior experiences with employers. But I'm digressing.

So I've been using it for two months. I'm still not sure if it's good for people that just want to talk or text, but it's definitely great to access the internet on the go. So I started catching up with my backlog of articles in Google Reader. Currently I'm back in January 2010, so there is hope that the folder with articles to read will be empty some day. (Alas, it's just one of four, so it looks like I will stay busy for some more months.)

Today I came across Ted Neward's Predictions. I like to read Ted's posts because he doesn't take himself too serious. I especially enjoyed his busy Java developer's guide to Scala two years ago, but I'm digressing again. In his predictions he talked about different technologies and some well known companies. I will not repost his post, but he made some quite sarcastic and funny remarks that I need to share.

• "Cloud" will become the next "ESB" or "SOA", in that it will be something that everybody will talk about, but few will understand and even fewer will do anything with. --- Well another one in the list of useless buzzwords that lacks a clear definition. Last year I was working on some enterprise integration project and the Czech bank was using AquaLogic ESB. I asked our rock star enterprise architects what exactly defines an ESB. They were not able to give a proper answer. According to the German Wikipedia the term ESB was defined by Gartner in 2002. So it's no wonder that ESB is not proper defined.
  
  
• Being "REST"ful will equate to "I did it myself!"
  
  
• Agile has become another adjective meaning "best practices", and as such, has essentially lost its meaning. --- What does best practice mean anyway? Most likely it is a cookbook and a collection of things that work. According to Andy Hunt best practices are for people that need guidelines. But these guidelines never capture the whole context of the problem. And Ted really hates best practices.
  
  
• Try this: walk into a functional language forum, and ask what a monad is. Nobody yet has been able to produce an answer that doesn't involve math theory, or that does involve a practical domain-object-based example. In fact, nobody has really said why (or if) monads are even still useful. --- When diving into Scala two years ago, I tried to figure out monads. James Iry did a decent job explaining what they do, but I still have no idea what they are or why I should use them. (But probably that's different for pure languages like Haskell.)

How true. Ted, you are great.

Slacking Off

... or why automatic checks are necessary.

Human Factors
I must confess, I'm a slacker. For example I've been writing this post for three months and still haven't finished. I skip my workouts again and again. More important things just pop up all the time. Concepts like interesting or important are subjective and priorities are likely to change between individuals and over time. So everybody has his or her sweet spot of slacking. It's impossible (and probably also unwise) to work hard on all aspects of life. When everything runs smoothly, people get sloppy. (Again that might be something good for boring, repetitive tasks - except when a surgeon performs his 1.000th appendix extraction.) When things work out great, we might even get delusions of grandeur and bathe in the glow of our own greatness. Everybody does it, you do it, I do it. Only Chuck Norris does not.

Hmm. I'm mixing different behaviours here: slacking, sloppiness, laziness, lack in motivation, doing things half-hearted, leaving things unfinished. I use all these words synonymously. I Know that's not entirely correct. (Probably that's the reason I can't get this post into proper shape. I've already rewritten it five times. I know that I must not ship shit but I'm getting tired. So I will have to live with it. I'm sloppy myself ;-)

There are several causes for these factors, e.g. lack of interest (I don't care), boredom (I do it the hundredth time), distraction (I'm not able to concentrate on it - I just love cubicle spaces.), lack of background information (why do I do this crap), fear of wasted effort (I might not need it later) and time pressure (I have no time to do it proper).

Oh My!
What implications do these factors have for code quality? (By code quality I mean the internal code quality, maintained by the developer day after day.) Consider a product 'A'. Features have been added to it for the last five years. The natural laziness of all developers has taken its toll. The code is a mess. Maintenance costs go up. Suddenly code quality gets important. Suddenly management is interested in coding conventions and development processes. Suddenly people are aware of a need for an architecture. Suddenly people want to stop slackerism. But when the product is in trouble it's too late. Not really too late, as software is soft and can be changed all the time, it's just much more expensive. All these things are not new. It's well known that software erodes over time. Slacking developers may just be one of its causes.

Check What?
After this lengthy introduction I prepared my point: The need for automatic checks. Checks are good for you. (Like daily sit-ups.) Do them. Even better, set them up so you don't have to do them yourself. (Somebody does all the sit-ups for you. Every day. Isn't it great ;-) Remember: if it's not checked, it's not there. Paper is patient, automatic checks are not. Really, make your checks and reviews automatic. It's important, like your daily vitamins.

Automated testing is only one aspect of checking your code, albeit the most popular one. The test infected community already knows that if it's not tested, it's broken.. So next to testing you need to check other aspects of your code, like coding conventions. Usually these include whitespace policy, formatting, naming and other design idioms. Coding conventions cover a much broader area than most people think. They are not only about naming. They are also about higher level boiler plate code, e.g. how to handle transactions, how to access the database, how to log, how to handle exceptions, etc. These things are project specific and depend on the overall architecture.

Check It!
All projects have some sort of coding conventions. But are they complete? Are they documented? Do developers comply with them? Unlikely. They need to be documented and even more need to be checked automatically. Probably most of your rules are not checked. It's time to write them down and define some concrete checks for them. Most tools and even some IDEs ship with basic rules for simple things like whitespace, naming or common coding idioms. These are perfect for a start. Start small. Use a few rules. You can always add more later. The limit of what you can check depends entirely on your determination: design rules, layering, modularity, architecture, code coverage and documentation and much more.

The problem is that rule enforcement provokes opposition. People don't want to leave their cosy comfort zone. Discussing and agreeing on a new coding convention is not a problem. But adding a new rule to already checked coding convention might be a fight. You have to convince developers to accept it. You have to argue with management for time to remove rule violations in legacy code. You have to struggle through, especially when you're only a grunt. Small steps are crucial. Don't press on it too much. If there is opposition, offer to drop the new rule. Make it look like there is the option of not having it. This enables discussion. (Of course that's not an option and you are not really offering it, but people like to have options to discuss about.) As soon as some rules showed their value, developers will vote for them if you oppose them, be the devil's advocate.

Automatic!
So let's finish this rant about human nature. I'm a slacker. Most likely there are some more in our trade. We must accept that. we are lazy. We make mistakes. Sometimes we are weak. That's normal. We just have to be aware of it. So be paranoid. Don't trust anyone. Automate anything that you might screw up. (Robustness #2) Automatic checks are your safety net. They help you avoiding making the same mistake twice. If there is a bug in your code, create a unit test to ensure the bug stays fixed. If you have inconsistent formatting, add format checks to your daily build. If you notice wrong usage of a design idiom during a review, create a custom rule to enforce proper usage. If ... well you get the point.

All this leads to the 2nd Law of Code Quality - Automatic Checks to fight slackerism.

Public Relations

It seems that I am particularly unlucky in finding support for my interest in code quality. I can't help ranting so I will tell you this little story.

Some years ago, shortly after my "career" as code cop began, I wrote a series of articles about code quality and daily build techniques for a Java magazine (which I enjoy to do from time to time). My boss knew about it, but was not interested in it and I wrote the articles in my free time. (As you might have noticed I am not a gifted writer and filling all the gaps between facts and source code took the best part of most weekends during that year.) The first part was published soon after that.

After some time the second part of the series was published. This time the head of the IT department (the boss of my boss) learned about it and was impressed. He thought I had done it during work hours, or at least should have. I was happy and thankful for his appreciation and of course did not object to being paid for the time already spent. But my boss did not like the idea. He kept saying that we (the company I was with back then) were not an IT providing company and did not need to show any technical expertise or qualification to the outside world. However as he was forced to pay me for those hours, a rather difficult time began. In the end I regretted having shown the article to anyone.

In fact the whole story depressed me a lot and made me accept an offer from another company half a year later. There, during my interview I was promised support for writing technical articles. Later when a new article was due I wanted to call on that. It turned out that neither a budget nor a process was available for such activities so the support melted down to being allowed to write in my free time. I was pissed but in the end couldn't blame my boss. It was entirely my fault. Due to my lack of bargaining skills I hadn't pinned down the promised support to something concrete. (Technically my boss had not lied to me.) So from this time on I did neither ask nor expect any support. If they didn't want it, they should have said it straight at the first place.

But that was not the end...
Several months later I attended a department meeting on improving internal education, knowledge transfer and being more professional in general. It turned out that the head of the department (the boss of my boss) wanted more activities seen by the general public and that they had problems fulfilling the request of upper management to place an article in internal journals from time to time. Imagine my confusion when I heard that.

Yesterday a colleague brought a small, local conference on software quality to my attention (shame on me I hadn't known it before) and proposed that I should try to submit a talk. Again I tried to get some support for it. I am able to prepare stuff at home (at the weekends) but I can't afford taking days off for giving a talk. This time I contacted the boss of my boss directly because I remembered his (feigned?) interest in public relations. Unfortunately he delegated the decision back to my boss. As we already know, she does not deem public actions necessary. :-( My colleague was surprised, too. We remembered the things being discussed during the departmental meeting and both had thought that management wanted more public relations. (Otherwise I would have started questioning my senses.)


What is going on here? Are they all dreamers, talking about things they would like to have knowing they can never afford them? Or is it just another form of the suppressing code quality because we don't have any-syndrom? (In full name I call this the suppressing code quality topics because we know that we do not have any quality and I will write about it later.) I don't know. But I do know that it was the last time they tricked me. (They've already tricked me twice, shame on me.)

Soft Skills

In our department there was a small team of three people, organising internal training, maintaining the library etc. One of them left and later in a departmental meeting a discussion took place about replacing the missing member. The remaining two guys said that they already have difficulties managing and synchronising themselves and a third person would not help and is therefore not needed. Well, it sounds reasonable so far.

Some days later I was asked by my boss if I would like to join the team, which I denied, because as I had earlier understood, they did not want a third person, even if management thought they needed. (Well maybe it's from the management "idea" that having even two employees working on some topic is risky, because both might decide to leave the company - but three might as well...)

Afterwards I talked to the head of this "education" team. I had denied not of disrespect for their work but because I knew that they didn't want a third person. I was surprised to learn that they had already found a suitable replacement for the missing third member. They were so happy that someone they liked had volunteered. Huh?

Did I get something wrong in the first place, or did they talk unclear, on purpose, so they could choose their third member themselves? The whole story is just strange. Obviously I lack some soft skills in communication...

Technical Progress and Joel Test

The Joel Test: 12 simple yes/no questions verbalised by Joel Spolsky in 2000 to determine the pain of developing software in some company. Since he wrote them, I have been using them to check companies if to work for a them or not.

In 2003 and 2004, I "checked" several companies during interviews or asked friends about their jobs. Back then I found that marketing and web design agencies scored lowest (1 out of 12), followed by little software shops and in-house development of small companies (2-3, sometimes up to 4). More seriously working software companies usually reached 6. That was it. Only one out of 20 companies scored 9, still not ideal. (Especially noteworthy was a mobile phone provider with more than 1000 employees having only a score of 3.)

In 2008 while looking for a new job, the companies I met were scoring about 9 or 10. I do not have much data to state any facts, but this feels much better than 4 years ago. The question is if there is such a tendency, a technical progress of the software engineering craft, that could be measured by Joel's test? Or is it just my experience telling me where to look for proper work now?

Update 28 February 2009

All Lies

After accepting an offer of one of these companies I found another reason: They were lying! They said they are able to build the product in one step. Well, that's somehow true but only after changing some hundred configurations in different files. And yes, it's also true that they have daily builds, continuous builds even. But nobody is watching the build status until a new release has to be created. That's hardly what I expect from a daily build. So their real score is 6 at most.

backwater, in-house development

Maybe I am too strict, or my expectations are far too high for the average company (which is likely the case). However, while staying with Herold I reached the conclusion that "backwater, in-house development" does not provide footing for IT innovation. Obviously this is true but the ironic part is, that management pretends that it's there. Listen to this:

Two years ago they came up with the idea of science Fridays. Every Friday the development department would be locked, so no one would disturb us and all developers would try out new stuff or study books. Well, it never happened. Last year the idea was still around, we would just start after this particular next release. And there is always some pressing next release to work on. The WTF of this paragraph is that two months ago I was asked by the boss of my boss if I used the science Friday time for some project. I had to laugh out loud.

Another idea was born at the beginning of last year: every month a member of the team would prepare some topic, e.g. new features in .NET 3, and present an overview. There was not a single one of these presentations, the monthly meetings were always full with lists of features to be put into the next release. The proposed topics, already outdated, are still in my boss' drawer, waiting for their time.

How about professional training? "Sorry, there is no budget for that. Sales revenue just increased by 5 percent last year. The company is in critical condition. We all have to work harder."

So I experiment with new technologies at home and try to bring in something new from time to time. But I was told that we do not need it, because we are no IT company and there is no point in spending time to stay up to date because it is not our main business. And anyway I am not supposed to spend "so" much work time on education and research. But I have to, because as Heinz Kabutz once said, we're in an industry with a knowledge half-life of at most 18 months. Keep in mind that half of what you knew 18 months ago is worthless today, so you need to keep learning new things.

Do you work under similar conditions? Tell me how you overcome them to stay a top notch developer.

My Rants

After years of being a maintenance developer I am pissed off. During maintenance the software systems are always messed up. Obviously the release date of the next batch or upgrade is set by the business analysts long before the exact extend of work is known. There is never time to fix anything. In my early days I would have argued with managers to add extra time for fixing the most ugly things during the next release, but finally I resigned from wasting my energies.

The Angry Developer
So I became an angry developer. Always in pain, I am using biting comments to point at serious problems in systems, processes and whole organisation. I will rant from time to time about IT work and software development related stuff.

For any legal departments reading this: The events and companies I am posting about are completely fictional and any resemblance to any real people or companies that may or may not exist is purely coincidental.