Monthly Archive: April 2012

About Passion

What does passion mean for a Software Engineer? Depends on the context. First, and that’s what start-up companies usually expect from their employes, it means you love the company, the business idea and the team you work with. Some people are also passionate about their Apple computer/phone/tablet in a similar way (the term “Fanboy” is frequently used in Web forums to describe this behavior). *

Second, it can mean that you stay ahead of the curve and have strong opinions about how to do your job (independent from the company you’re currently working for): For example, I’m obsessed with clean code and unit tests. When I’m using a component library and come across a class that does not work for my project (too slow, too many bugs, too complex or does too many things at once,…), I insist on looking for an alternative from another library or even write my own code to replace it. When I see the need for a refactoring, I will do it. Although this is a certain effort and not the “easy way”, I am more than happy to do it because it is better than producing a mess in the long run. It’s not good enough to have a halfway working solution and collect technical debt, just because you are too lazy, somebody insists on using the “standard library” or says “there is no time for refactoring”. It’s also not good enough to omit unit tests because “the class can not be tested”. Passionate developers commonly contribute to one or more open-source projects.

So, in the first case, the concept of passion is used by others to either convince you to put a lot of energy & time in a low paying job at a start-up company or to increase Apple’s revenue. Either way, you tend to give more than you normally would. While this can be fun and create a shared identity it is also unprofessional, because it makes you blind for other opinions or criticism. Note that I’m not saying you must be professional at all times.

In the second case, you have the passion to do whatever you are convinced leads to desirable work results. This can surely be seen as arrogant behavior when you try to enforce something within a system that not everyone agrees with. On the other hand, your opinion is usually based on solid professional experience and it would be strange to make the same mistake twice just to avoid a discussion and conflicts. The Challenger explosion is an interesting, although extreme example. Let me quote a few lines from the preface of The Clean Coder:

“Certainly the engineers did what they were supposed to do. They informed their managers and fought hard for their position. They went through the appropriate channels and invoked all the right protocols. They did what they could, within the system—and still the managers overrode them. So it would seem that the engineers can walk away without blame.

But sometimes I wonder whether any of those engineers lay awake at night, haunted by that image of Christa McAuliffe’s mother, and wishing they’d called Dan Rather.”

* I’m not blaming anyone for using an Apple device (this blog post was written on an iMac), but there is strong evidence that this company consciously uses passion for its marketing strategy, see or

Wunderkit and the 6Wunderkinder – 8 months later

As you can see on my Linkedin profile, I used to work as consultant for 6Wunderkinder, a Berlin based start-up company, last year. My job was to provide training for the developers and help building the initial Web frontend for Wunderkit, their next product after the popular Wunderlist app. Even though I could say a lot about what I liked and didn’t like about any company I worked with, I’m never disclosing internal details. The reason they hired me clearly was my experience with large Web applications and JavaScriptMVC. One of the reasons they stopped working with me obviously was that they decided to use BackboneJS as framework for the Web frontend instead (while I was on vacation in Chicago…). There are some public tweets about that, so I’m just repeating it here – basically, they complained that the head revision of JavaScriptMVC was not stable enough. Of course it would have been nice to find a solution, but at the end of the day it’s their responsibility, right? It’s their company and they must do whatever they feel is required to succeed!

From that perspective, I’m very much interested in how the move payed out. After they released the Wunderkit beta, it also came to my attention that they not only replaced the frontend framework but also switched from PHP to Ruby on Rails in the backend. That explains the delay and makes the comparison to my preferred technology stack even more exciting. Not sure how this last sentence sounds, it’s not ironic: I really like to see their efforts result in another hugely popular (and mature) application like Wunderlist. So far, it can be said that they managed to release a Wunderkit beta to the public and that the site is up and running. That’s good. On the other hand there are reports from users that lost all their data (see iPhone app store). I’m sure PHP developers can make their own sarcastic comments now. To be fair, it’s still “beta”, so anyone who stores important information on Wunderkit without a backup should not complain – in theory… The performance of the Web frontend did not convince me at first, but seems to get better. I’m sure they’re still working on it. Therefore, I will wait with any in depth analysis, until they declare the application stable. Good luck guys! :)

Another question is, if the feature set of Wunderkit is a fit for the users. Sometimes, it’s not easy to differentiate between technical issues and usability issues (“It’s not a bug, it’s a feature!”). My impression is, that the public reception of Wunderkit is mixed. Not everyone is as impressed, as the (often criticized) hype suggested. There are many blogs discussing the features and usefulness of Wunderkit (you know how to use Google).

What makes me wonder is, that some employes left the company, which is generally not a good sign. For example Jessica Erickson, Michael Henriksen and Ricardo Sousa. Ricardo wrote an interesting blog post about his Wunderkinder experience. He mentions that some employes are more passionate than talented, which is something I probably wouldn’t publicly say about my customers. He used to work there after I already left, so I have no clue what exactly he is talking about. Of course there are not only senior developers working in a start-up company – that’s clear. From my perspective, everyone is more passionate than I am. Hope that means I am at least talented. IMO producing quality code and working efficiently is my professional duty – otherwise I would rather spend my time hanging around at the beach and drinking cocktails, seriously.

The Clean Coder

I’m currently reading The Clean Coder by Robert C. Martin. Here are some of my favorite quotes:


“There is no doubt that some of us can make more efficient use of our focus-manna by consuming moderate amounts of caffeine. But take care. Caffeine also puts a strange jitter on our focus.”


“Programmers tend to be arrogant, self-absorbed introverts.We didn’t go into this business because we like people. Most of us got into programming because we prefer to deeply focus on sterile minutia, juggle lots of concepts simultaneously, and in general prove to ourselves that we have brains the size of a planet, all while not having to interact with the messy complexities of other people.”


“I have consulted for teams that failed to take broken tests seriously. They were ‘too busy’ to fix the broken tests so they set them aside, promising to fix them later. In one case the team actually took the broken tests out of the build because it was too inconvenient to see them fail. Later, after releasing to the customer, they realized that they had forgotten to put those tests back into the build. They learned this because an angry customer was calling them with bug reports.”


“The unit tests are documents. They describe the lowest-level design of the system. They are unambiguous, accurate, written in a language that the audience understands, and are so formal that they execute. They are the best low-level documentation that can exist. What professional would not provide such documentation?”


“I’ve seen products ruined and companies destroyed by software messes. I’ve seen the productivity of teams decrease from jitterbug to dirge in just a few months. Nothing has a more profound or long-lasting negative effect on the productivity of a software team than a mess. Nothing. […] At some point you realize that you made a wrong design choice when you started, and that your code doesn’t scale well in the direction that the requirements are moving. This is the inflection point! You can still go back and fix the design. Going back looks expensive because you’ll have to rework the existing code, but going back will never be easier than it is now. […] There is no sadder sight than a team of software developers fruitlessly slogging through an ever-deepening bog.”


“Somehow the software development industry has gotten the idea that programmers are programmers, and that once you graduate you can code. Indeed, it is not at all uncommon for companies to hire kids right out of school, form them into ‘teams’, and ask them to build the most critical systems. It’s insane!”

Eclipse is not the solution!

During the last couple of days, I’ve been updating my posting about cargo cult coding standards for PHP. There are some examples now. Thanks to Arturas Smorgun for retweeting it. I’m sure my post doesn’t have a huge impact on the community, but for me it’s still worth talking about my experiences.

Guess what’s bothering me the most is that the popular PEAR/Zend Framework coding standard actually forces you to lose the context of your currently edited code. Things like the maximum line length or the underscore prefix of non-public class members are just minor issues. Adding mandatory inline comments (that mostly duplicate your code) and new lines after declarations wouldn’t be that bad, if it wouldn’t waste so much vertical space (and therefore hiding your context). When I talk about this issue, the usual answer is, that you simply must use Zend Studio (or Eclipse PDT), which automatically collapses/creates phpDoc comments and jumps to related functions. The funny thing is, that Eclipse is so slow and unreliable when working with large projects, that it is exactly as bad for the development efficiency as the coding standards mentioned. This shouldn’t be a satisfying  situation for any professional developer. Developers should be able to work with the editor of their choice, as long as it supports automatic indentation and UTF-8. Maybe that’s wrong, but I totally refuse to make my PHP coding standard dependent on some Java editor software.

Bottom line: The PEAR/ZF standards and Eclipse/Zend Studio were made with the best intentions, but in some points they conflict so obviously with the practices taught in Clean Code (not to mention common sense!) that you must either reject them or close your eyes and hope for the best.

Cargo Cult Coding Standards (CCCS) for PHP

Cargo cult means that you copy some (previously) successful behavior from others and expect something good to happen to you (or your project) as well. For coding standards, that’s a very good starting point. Especially since formatting standards are often not based on any science – life is just easier, if everyone is using the same formatting for source code and we all hate the discussions at the start of projects, when some junior developer tries to promote it’s own fancy ideas.

However, during my work as Web software developer and consultant, I found a couple of standards that should be re-discussed. Not so much because they uglify code (sometimes they do), but because they can be truly counterproductive for code quality and developer efficiency. Often these standards had their reasons in the past, were borrowed from other programming languages such as C or apply to certain types of software only (e.g. framework libraries).

1. Document all source elements: Files, classes, methods, variables and annotate with comments, type hints, and other useful data.

That’s the worst of all recommendations! Is it possible to create more confusion and duplication any other way? No. I agree with Robert C. Martin who says: The code is the only source of truth. Why would I prefer to read a comment instead the actual source code? Why would I want to waste my time commenting bad code instead of refactoring it? Why would I want to risk outdated comments that lead other developers in the wrong direction? It’s way better to use good class, function and variable names than using phpDoc comments for each and every element of your class:

 * Add a CD to the list
 * @param string $title The title of the CD
 * @param string $author The author of the CD
 * @param int $numberOfTracks The number of tracks on the CD
 * @param int $durationInMinutes The duration of the CD in minutes
public function addCD ($title, $author, $numberOfTracks, $durationInMinutes) {
    $cd = new CD();
    $cd->title = $title;
    $cd->author = $author;
    $cd->tracks = $numberOfTracks;
    $cd->duration = $duration;

Also, if there are comments everywhere, you won’t notice the really important comments like “// Don’t run this code on the production server! It deletes all data!”. Zend Studio sometimes needs a type hint – in that case you can easily add a phpDoc block where needed without cluttering all your code upfront, wasting your developers time and your customers money for no good reason.

It’s OK to add lots of phpDoc comments to public libraries such as Zend Framework or Symfony, but that’s a very special case that should not be generalized. Public libraries often use those comments to create API documentation on their Web site – although I have to admit, that I never read the automatically created documentation (Maybe others do? If there is no “real” documentation available?).

In my opinion, it is way more helpful to have an external documentation (a Wiki, or even a constantly updated Word file) than inline documentation that just duplicates class and function declarations without giving you true insights about how the whole system works or is supposed to work (that is often more interesting than the actual implementation).

My advice: If you really want to “comment” your code, write good unit tests, that show how to use it, instead of adding endless phpDocs. Lots of inline documentation is no sign of good quality. (That may be true for C code, because it is difficult to read even if the developer tries his best.)

2. Non-public class members should be _underscorePrefixed.

This is a common standard in the PHP world, but absolutely unnecessary since PHP 5 was released. PHP 5 has built-in visibility support. Underscores not only make your code look ugly, but they also complicate refactorings: You always have to rename all (!) occurrences of a function/variable each time to change the visibility. Last but not least, it is an obvious duplication (don’t repeat yourself). Just because the standard was a necessary evil for PHP4 projects doesn’t mean we need to do it for the next 20 years, even though there are better ways now. As far as I know, this convention was dropped for Zend Framework 2 – that’s a good thing, but shows how long obvious issues need to be discussed by the community until something changes.

My advice: Simply don’t use that underscore. Everything will be good.

3. Functions and Classes should have the opening brace on the line following the declaration, at the same indentation level.

When I saw this the first time in PEAR, I didn’t like it. But more importantly: I didn’t understand why somebody would waste that much vertical space for no reason.

Later I found out that there actually is a very plausible reason for this convention: You can clearly see where the function/class body starts, if the declaration uses multiple (!) lines, e.g. if the class names are extremely long (should not happen with PHP 5.3 namespaces) or a function has a lot of parameters.

class My_Db 
    extends Zend_Db 
    implements ExampleInterface
    public function foo($arg)
        return 'something';

    protected function _bar($arg1, $arg2, $arg3,
        $arg4, $arg5, $arg6
    ) {
        $result = $this->_doSomething($arg1, $arg2, $arg3, 
            $arg4, $arg5, $arg6);

        return $result;

This is exactly, why I don’t like it: A function/method should not have that many parameters, because it’s very difficult to test (and to use) functions with – let’s say – more than 3 parameters. A more detailed discussion can be found in the book Clean Code by Robert C. Martin. Rather you should instantly notice that a refactoring is needed, when you reach the defined line length limit. In my perfect world, the code should look like this (the extra space after the method name is intentional to make declarations optically different from invocations):

class My_Db extends Zend_Db implements ExampleInterface {
    public function foo ($arg) {
        return 'something';

    protected function bar (My_ValueObject $values) {
        $result = $this->doSomething($values);

        return $result;

Note how readable and compact this is. Another major reason not to waste vertical space (by adding useless comments or new lines after declarations) is to display as much context (functions related to the current function) as possible in the editor. If you use a lot of small functions (as it should be), you will notice that not adding new lines or useless comments helps tremendously. I know comments can be hidden in some editors, but if you ever used Eclipse, you should have noticed that using it is an impediment by itself (“Please wait for the background operation to complete”).

My advice: This small difference from the Zend Framework/PEAR standards usually is not a big deal and many developers will agree it looks better and saves space. Just don’t mix the styles in the same file.

4. Keep lines 75-85 characters in length, maximum.

That (still often used) rule is questionable in the year 2012, considering that it’s almost impossible to buy a computer or notebook without a wide (!) screen. Vertical space is very valuable and limited but horizontally you can easily allow 120 characters without getting into trouble. Of course, your code shouldn’t use it very often – it’s just the maximum. Readability of the code usually is reduced because of bad function/variable names and huge function bodies. I never had trouble reading PHP code because the line was too long.

My advice: Define a maximum level of nesting instead of limiting the line length to 80 characters fixed.

5. Use the Singleton pattern, if you need only a single instance of an object to be accessed during the request.

Guess I don’t have to say much here. The modern version of this advice should read: “Use dependency injection to create shared objects.

My advice: Use the mature dependency injection container of Symfony Components.