Personal Problems

So here is my computer, I switch it on, it boots. Life is coming into that electronic miracle. Humans made an operating system for data storage and application execution, first of all Linux, the free operating system for the masses. Now I start editing this document. Humans made software that runs on top of the OS and helps us with our daily issues, first of all Java applications with its strong internationalization approach, that made software available on most OS platforms and for many cultures of the world. (OK, I admit that I do not edit this HTML document with a Java application ...)

Humans - the plural? Didn't Bill Gates work out the Microsoft operating system? Didn't Linus Thorvalds write Linux? Wasn't it James Gosling that created Java?
I assume they were not alone. There are not many things left that one can do alone, complexity is overwhelming.

So how do humans work together? Do they work together? Or do we have managers that put together the things that software developers work out alone in their ivory towers? Or are software developers managers that put together detail solutions that have been worked out by universities and open-source projects? I believe to understand that there is no simple answer to that questions.

When working in a software development team you soon find out that a lot of work is done in vain. And even the things that can be sold are aging quite quickly. You need a lot of time to keep it alive and running. In the backyard technology is growing and changing all the time. Sometimes I have the impression that the developer is more a journalist than a technician. He/she is adapting the software all the time, and in breaks refactoring is needed. But we are not alone. Nobody is an island. Together we are strong. ... Any more phrases about collaboration?

Personal problems occur everywhere in human collaboration. But lets focus on those problems that are neither financial nor emotional nor educational. How can a crowd of well-motivated, well-paid, well-behaving, polite and educated developers work together?
Answer: They dicuss problems and design solutions. They write specifications, sourcecode, comments and documentations. They choose technologies and integrate them. They fix bugs and refactor weak concepts.
Well spoken, now lets evaluate what happens in the real world.

• Discussion - isn't this tedious and a waste of our expensive time?
• Design - why do that when source code can be written much faster and already does what was intended?
• Specifications - we use API's, but do we need API quality in our final applications? I mean, the code IS the specification ...
• Sourcecode - yeah, my code is the best, fastest and trickiest, forget the rest ...
  
• Comments - was identified as a "sweet code smell". Good object-oriented code is self-documenting. Comments are redundant.
  
• Documentations - why do that when we have sysadmins and sales staff?
• Technology - I use XXX and nothing else. Works good. Have been doing that for years. Don't like all that new things ...
• Bug Fixing - this is just about putting my glorious source code into that old bad one.
• Refactoring - isn't this a theory-heavy thing for academics?

Reality shows us that collaboration can be quite hard, even with well-behaving developers. Reality shows us that every coder likes his own code and nothing else. Reality shows that developers are rarely able to write understandable specifications or documentations (glad that there are not so many typos even in source code). Reality show us that they are not behind sustainability or maintainability but behind feelings of success. These are our personal problems.

But lets focus on the real developer problems, admitting that discussion, design, specification and documentation is not the real responsibility of a developer (even if they do it all, including organizing beer). I have made a list of things that happened in nearly all developer teams I have been working since 1991.

1. Copy & paste of existing source code is the default technique for solving new problems. Abstraction is not very popular and is deferred to the refactoring phase (that never happens).
2. Code is written for the machine, not for humans. Names for classes, fields and methods are chosen arbitrarily and never get improved.
   
3. Only few developers are interested in the fact that there is already a solution for standard issues, for example, date rendering - "How can I find this?" "I do not want to depend on this." "This is too special, I need it a little different".
4. Comments, if they occur at all, are kind of context-blind, which means they rarely make sense for other persons than maybe the author itself. Classical example: "foo(); // now we call foo()". Currently Java sources are full of comments generated automatically by Eclipse IDE.
   
5. Introducing solutions that affect a lot of other developers seems not to be a reason to present it, discuss it, then implement it, and after a while review it. Mostly they get more or less forced into the project without asking anybody. The attitude is "You have been waiting long for that, haven't you?".
   
6. Informations are exchanged as attached documents except of using hyperlinks into the intranet, where the information could be OnceAndOnlyOnce and always up-to-date.
7. Wikis, when used, degenerate after a year to un-navigable piles of unreviewed writings, noticed by nobody.
8. Communication is preferably practiced as smalltalk, while smoking cigarettes or drinking coffee. Decisions are made in a sneak attack style without having heard affected participants. Regular jour fixes are considered to be too tedious.
9. Problems are solved in the last moment by mostly weak ad-hoc solutions that often stay for years then. Long-term planning is flushed away by the daily troubles.
10. No space is left for learning and training. Team members are expected to practice learning-on-the-job, or in their spare time. Exchange of experience is not facilitated. Skills and profiles of members are not known, even when they were hired especially because of those skills.
    

You might say now "Why bother? We know that all!". I do not bother. I state that these things make software development tedious, cumbersome and frustrating. And it hits the project. You get out source code with 90% maintainance and 10% authoring efforts. Isn't this what kills all the startups?

So, what to do against that.
Hire a senior programmer that walks through the rooms, always smiling and ready to give profound help on any problem. You might get a frustrated guy that always locks himself into his room. Or he will be mobbed out in less than a month.
Organize discussions and design sessions, trainings, send the developers to courses to get certifications. Your chief will ask you who should pay that all.

I mean I do not know how software developers work together. I accept chaos, else chaos would not accept me. Some people state that it is not like that in other countries (everything is better in America). I try to behave like I was in another country. I notify other developers by mail or in jour fixes about the things I have done. I try to publish and sell my software within the team I am working. I try to be a journalist as well as a technician. I am always ready for collaboration, even if it does not happen.

Wish a good day.


_____________________________________________________________________________________