Showing posts with label Blue Company. Show all posts
Showing posts with label Blue Company. Show all posts

16 August 2013

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.

One Does Not Simply Write His Own DatabaseRoll 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".

Madness? No This Is ReliableFrom 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.

16 December 2012

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.

WaterfallSome 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.

First Dorogando (final)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.

14 April 2012

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.

I've got a new friendFinding 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. 12 A 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
Missile CommandI 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.

5 January 2012

Legal Disclaimer

Judge DreddWorking for big companies has advantages as well as disadvantages. One of the advantages is that they have attorneys for everything. So to be sure, I make the following statement:

The opinions expressed here are my own and do not necessarily represent those of current or past employers.

Any attorneys reading this please further note that:

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.

The content provided on code-cop.org is CC BY licensed. (Images might have a different CC licence.) Code is BSD licensed.

2 January 2012

Code Cop goes Blue

It has been six months since I went "blue". After having some minor problems in the beginning I have settled down. Recently I completed the second learning plan on how to become a true IBMer, so I feel like changing my Code Cop character a little ;-)

Code Cop

6 August 2011

Diaries of a New Employment

SkyscraperI 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.

  • DiaryDay 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.