Trust your developers

There haven been quite some good articles written about trust. If you want to start somewhere, read “Building a Culture of Trust” from Derek Brown. (No, really, go and read that article!). I often notice that people understand the need for trust and are willing to incorporate this in their companies. But more often than not, they fail in trusting developers. Ask yourself if you have experienced situations like these:

  • You get an estimation from a developer how long development of a certain task/feature/project might take. If it’s to high, the bargaining start until they come up with a better “estimation”.
  • Your developers tell you repeatedly that some piece of code needs to be refactored, but as things are working quite well for some years now, new features get a higher priority than the refactoring task. (BTW: It’s not always reasonable to improve a product by adding features).

Yes, I know that estimations are hard. But who could do it better than your developers? Yes, I know that refactoring seems useless from a business perspective. Put a lot of effort in a running system without getting visible output seems stupid. (At Quora, they think differently). Let’s assume for a moment that the people you (or your company) hired are smart people. It’s perfectly fine then to agree that at every given moment, they do the best they can given their abilities and the information they have.

So, if something goes wrong, it might not be their fault. You can adjust their abilities (by providing training) and the information they have. If your developers fail you, probably you have failed in these areas. But it’s hard to accept this and it’s far easier to blame them for your shortcomings. But doing this will lead to distrust in both directions.

Let’s face it: By allowing developers to develop your product, ship your features and deal with potentially sensitive customer data you already give them a lot of trust. Ask yourself why it’s so hard to accept that they do the best they can?

Why Implementation of Continuous Integration fails

It’s nothing new that Continuous Integration (CI) should be part of every somewhat professional development toolchain. In reality however, I’d estimate that at least 4 out of 5 development teams make no use of CI whatsoever. Why? I think it’s more or less out of inconvenience. I tried to set up CI in a working way for me or my teams more than once, but without notable success so far.

There is probably no single reason, but – let’s face it – it starts with Jenkins (the de facto standard) being ugly, difficult to maintain and quite overwhelming for casual users. Sure, it’s probably mighty like hell, but the learning curve is simply to steep to get people into it.

However, let’s assume you managed to get Jenkins up and running. You can do all kind of funny things with your codebase. Running static code analysis and automated (unit and/or acceptance) tests are probably the popular (and reasonable) ones, but possibilities are endless. And this is another problem I observed once or twice: Once data is coming in, you get basically killed by the amount. Realizing that 69% of your codebase does not comply with PSR-2 is not helpful. Excuses are always at hand, most of them contain the words “historical” or “legacy”.

Looking at unit tests makes the situation worse mostly. Coverage is somewhere below 30%, and at least 40% of the tests are failing. Not everybody in the team has written tests before, knowledge is reduced to some tutorials or the exams you have to pass at university.

Ok, you know by now that you codebase sucks. Asking your product management team for a 6-week feature freeze to clean up you code base is not an option. So what happens usually is that you get used to a complaining Jenkins, disable mailings after a while and Jenkins is getting sad because despite all his efforts, there is no real improvement visible.

So if you want to implement CI for your team (and you should want this), you have to consider two things: The learning curve of your CI-Tool and the amount of information you create. Start small. Disable as many features as possible. Focus on one or two metrics for a start. Ideally metrics that can improve over time and that to not indicate how bad you are as a team and that your application is likely to explode more sooner than later.

Let’s say you start with PSR-2 compatibility of some newer part of your codebase (PHP_CodeSniffer can do this). The world does not end if you have errors there – but as long as these are not too much, you can fix them. Get used to include the CI server in your development process, have a good laugh if somebody “breaks the build” (i.e. violates that standard) and let him fix it instantly.

Once people consider it natural to think about the CI server when committing, expand from there. If possible, extend the test to the whole codebase (directory by directory if needed). Then add more tests (PHP Mess Detector has a lot to offer). Stick to static code analysis at the beginning, because there are no other dependencies. The only thing that can break your “build” is somewhat incorrect code. Once you start with unit tests or acceptance tests, there is way more to consider. Another direction where you can expand is the IDE of the developers: Your IDE of choice probably supports phpcs and/or phpmd locally as well, helping to keep the build green.

Evaluating Ideas

Following up on yesterdays post, it should be obvious that while omitting features might define a product, any product has to have at least one feature. And once you have a product you will always be tempted to add more features into it. How do you decide which features that would be? Eileen Webb has some inspiration on this.

It can be pretty hairy to narrow down the list of potential features. If the ideas were developed a while ago (which is usually the case in my projects—brainstorming tends to happen before outside consultants are hired), people are often very attached to an idea that they love and don’t want to give up.

I’ve found that what works best for me in these whittling sessions is to have a framework to fall back on. An established framework means that no one is trying to justify their idea to me; all ideas are evaluated in a relatively emotion-free setting so we can decide which solutions are the best ones to pursue.

Features do not define Products

So, Evernote seems to be in trouble. John Gruber claims:

It looks like the result of a company that is focused on adding features, not focused on creating something well-designed.

Which leads to some interesting thoughts. I had similar issues with Evernote. The overall promise sounds desirable: Having all your notes, clips, thoughts in one place, accessible from nearly everywhere and add some cool features that make the work even easier (like OCR, the nice clipping tools Evernote provides or the suggestion of related notes). Because of this promise I started several times to use Evernote as my primary note-taking system. I even copied old notes from random text files and all that stuff. In the end it never worked out for me and I always reverted to using the Notes app on iOS / OS X, synced via Google (and via iCloud lately). So at least for me (and as it seems for several others as well) features did not define or improve that product. They didn’t even add enough value to keep me using Evernote.

Coming from the other side, there are a lot of examples of really successful products which were lacking features or were even defined by the absence of features.

  • Google (I’m referring to the search engine here) was the place to go when Internet search was in the hands of sites like Yahoo or Altavista. They stripped everything, reducing their homepage to a logo and an input field (and kept ist that way till today). They delivered impressively relevant search results and that’s about it.
  • Twitter came along, allowing only 140 characters per tweet. A short snippet of text you could publish and the world could read it. Nothing more. The “feature” here was an artificial limitation – one could argue that the avoidance of features was the real feature.
  • When the iPhone debuted in 2007, there were neither 3G nor MMS available. Both were standard features in basically every other phone on the market back then. (Unlike Google and Twitter, the removal of these features did not define the product, but I think we can agree that omitting these features did not harm the overall success of the iPhone).

So overall it’s quite obvious that it’s impossible to define a product by looking only at the features it provides. More features do not necessarily improve the product and omitting features does not necessarily make the product worse or unsuccessful.

The world does not need another blog

But maybe I do? Inspired by an article on A List Apart I thought, I’d once again start to write some posts. Not for someone out there, not for the fame or anything, just for me. Sorting my thoughts, storing and sharing links beyond bookmarking them, whatever. I really don’t know where this will lead me, but I consider the thought intriguing enough to start this blog.

The timing could be better, of course. My new Job at esome will certainly take a lot of my time. On the other hand, I might learn a thing or two there and will certainly shift my perspective a little, so there might be interesting things to share.

Above mentioned post on ALA has a nice quote in it which I will follow as strict as possible:  “Treat your blog like your drafts folder.” I guess this might be the one thing that will help content to be published, as it will lower my expectations toward the quality of work here. So if you intend to follow this blog, keep this in mind and embrace it.