My Year 2014

My year 2014 was interesting and brought many changes from a professional and personal perspective.

From the personal perspective …

I had two great vacations: I was literally beginning the year under water on a great dive trip in Raja Ampat. Diving with oceanic mantas was something I will never forget:

And my mountainbiking vacation in Colorado/Utah was another extraordinary experience:

However the probably much more profound event in my personal life came in October with the birth of our first child:

From the professional perspective …

I started to do much more teaching in 2014. My engagement at the Berner Fachhochschule was expanded and I am teaching a mayor part in the new CAS (Course of Advanced Studies) “Multiplatform Development with HTML5” and a smaller part in the CAS Mobile Application Development.

During the year I was giving quite a lot of inhouse courses for JavaScript development and AngularJS. These courses range from 1 day bootcamps to 4 day workshops. I held courses for UBS, BIT, Puzzle ITC, Glue, IMS AG, ESGroup and I could again give my JavaScript Bootcamp twice at the ch/open Workshoptage.

I enjoy working in the emerging space of “JavaScript as a serious application platform” so much, that I quit my job as a architect at my former employer. I am now working as a freelance developer and trainer with my own company.
The adoption of JavaScript in enterprise application development is the area I am currently focusing on.

In the typical educational institutions JavaScript is still pinned to the space of “Web-Design”. Apart from that there are almost no public courses to learn professional JavaScript development. Thats where I try to offer my inhouse courses: I specifically target typical enterprise environments and enterprise developers (Java or .NET) and I try to show the similarities between the modern JavaScript ecosystem and the traditional enterprise plaforms and also the pitfalls of JavaScript. I am offering courses for professional JavaScript development, for AngularJS, for React and for architecting modern html5 based frontends for enterprise systems. But I always tailor my courses to the specific needs of the individual team.

For the coming months I have already engagements for courses at Postfinance and at Mobiliar and I am looking forward to work with more teams. If you are interested in setting up a JavaScript/AngularJS/React course or coaching for a development team, please contact me.

There are also public courses scheduled, where I will be teaching:

• Digicomp: Einführung in die Frontend-Entwicklung mit JavaScript und AngularJS
• BBV Academy: Professional JavaScript Development for Java & .NET Developers

Starting from April I will also be looking for opportunities to work hands-on in interesting projects. Of course my preference would be to work in projects where JavaScript and enterprise systems intersect.

Software: To eat and get eaten…

It has been declared:

Software is eating the world!

- Marc Andreessen

 

But lately it seems like:

Management is eating software development!

(Or at least it's sucking out all the innovation and creativity which used to be a major part in software development)

 

Some public indications of this trend are:

• Marissa Mayer introducing QPR (Quarterly Performance Review) Ranking System at Yahoo
• Google effectively killing its "20 Percent Time", which allowed employees to work on side projects.
• RedHat middle management putting performance pressure on one of its most prominent open-source community leaders. 
• Corporations swallowing and suffocating Agile.

Is this a bad thing or is it just a sign that the software industry is growing up? Does this boil down to the old question whether software development is craftsmanship or manufacturing?

Dysfunction: Headhunters & Short Time Contracting

I blogged before about the desolate state of our industry.

Here is one clear symptom underlining once more that there is something wrong:

Regularly when a government IT project here in Switzerland has an open vacancy for some months, I am getting calls, emails and XING requests from headhunters from Germany and the UK that want to mediate me for this job.

There is so much wrong in this setup...

For a start, the whole setup represents the idea that constructing software is like putting bricks on top of each other to build a pyramid. You can hire some more hands and you will finish sooner, because once a brick is laid, somebody else can put the next brick on top of it. This analogy is completely wrong (and that is not an expression of the unprofessionalism of our industry)!

On the other hand what does anybody expect when he goes through headhunters like this (I even have seen cases where several hierarchies of headhunters were involved)?

Do develoers think they don't get jobs without them? Do employers think they do get better developers through those headhunters?
What added value does a headhunter provide in this case? He hardly even looks at my CV, which is online anyways, and...? The employer wants to do an interview with me anyways, and the headhunter does not provide any guarantees, does he?

The result is that another layer of indirection is introduced that legitimates just another bureaucratic overhead. Headhunters like this are neither interested in the project nor in the developers they mediate.
Also (probably as a consequence) developers recruited in this manner usually are not very committed to the project. Why should they? The next recruitement is already waiting around the corner...

I strongly believe we should stop this headhunter/short-time contracting in IT projects. Hire developers for goals not time-periods. Cut the middle-men and get developers committed and responsible.

Further reading:

• Recent Thoughts On Hiring and Being Hired
• Headhunter tries to recruit DHH (funny comments...)
• 5 things that are wrong with recruiters! (Update 2011-11-29)

If you like this, follow me on twitter ...

TechTalk Event: What can you develop in 24 hours?

On April 14th my co-worker Thomas will hold a very promising presentation about Rapid Application Development with modern development tools.
He will present the findings from a daring experiment:

"One application, three platforms, 24 hours: Mission Impossible"

They took an existing ASP.NET MVC 3 application and wanted to find out how much of the given functionality can be re-implemented in 24 hours with the following platforms:

• Microsoft Visual Studio LightSwitch
• Ruby On Rails

Sounds like an epic battle: Rails vs. LightSwitch? If this does not have the potential for an endless flamewar, I dont know what has?
Everybody is welcome, including zealous Rails fanatics and corporate CTU agents ...
The event will be presented in German.
Date: 13.04.2011
Time: 16:30 - 18:00 Uhr, afterwards Apéro und Fingerfood
Where: Technopark Zürich, Technoparkstrasse 1, 8005 Zürich
Register online, the event is free!

Update 2011-04-24: The presentation is available online on vimeo (in german)

follow me on twitter, I need some friends :-)

Quotes of the Week: Motivation

I love my work. Yet put me on a team with unclear goals, little collective responsibility, arguing, and infighting, and I'll wake up dreading going into work.

- Energizing Work by James Shore

On the morning of his two year anniversary at the cubicle company, Ashton was driving to work when he realized something.

Not one line of code that he had written had ever run.

Not one thing he had done in two years of work made any impact on the world.

- The Story of Ashton by Joel Spolsky

In corporate environments the product don't have to be good. Sometimes they don't even have to exist ... if you are a thoughtful developer, you are in the wrong place!

- Jeff Attwood on Stackoverflow Podcast 41.

In reality I have almost never met a passionate developer, that is really happy with his job.

- I do like my profession, I don't like my job by Jonas Bandi

The productivity difference between a happy developer and a disgruntled developer is enormous, and constantly underestimated.

- The Framework Myth by Mike Mooney

 

follow me on twitter, I need some friends :-)

Rewrite It!

For a lot of projects a throw-away prototype would be the right thing to do... but people are very afraid of throwing away software.

This idea of throwing away your project can even be taken further than prototypes! TekPub has proven that, read it here:

• Architecting TekPub - Moving from ASP.NET MVC to Ruby on Rails
• Upgrading Tekpub with Rails 3

It seems that TekPub has been completely rewritten two times since going into production about a year ago (and several times as spikes before and after going into production).

This is the very realization of some interesting concepts:

• Deliberate Discovery
• Build Less
• Race to Running Software
• Ship It
• Rework

 

Compare that to your corporate legacy enterprise project ... sure it can't be compared, but why? Couldn't a rewrite be more effective than the uncontrolled growth we all observe in legacy applications?

It would mean that you also have to keep your enterprise applications slick and lean. Why is that so hard in corporate IT?

The challenges in rewriting legacy enterprise application are probably the missing stakeholders, the missing original goals and the lost knowledge of the current teams. And those rewrites that are attempted often end up in a gigantic technically driven framework monstrosity... probably because that is easier to do than thinking about business value.

This seems to be an omnipresent pattern and leaves the sour question if corporate IT is really the place you want to be ... especially if you compare it to the seemingly challenging and adventurous parallel universe of web startups.

follow me on twitter, I need some friends :-)

On TechTalks Mind: New Podcast Episode

Check out our new podcast episode. This time Claudia talks with Willy about requirements gathering in Scrum projects. This is a german episode.

Visit "On TechTalks Mind" or subscribe in iTunes.

follow me on twitter, I need some friends :-)

 

Parkinson's Laws

I only recently stumbled over Parkinsons Laws, even though I think in the IT business we are constantly confronted with them:


Parkinson's Law:

Work expands so as to fill the time available for its completion.

Who has not seen self fulfilling estimations?


Parkinson's Law of Triviality:

Organisations give disproportionate weight to trivial issues.

(the time spent on any item of the agenda will be in inverse proportion to the sum involved.)

Think of this next time you are on a meeting discussing the pros and cons of using underscores as prefix for member variables ...

follow me on twitter, I need some friends :-)

BDD Breakfast in Zürich

Next Tuesday (16.3.2010) my employer TechTalk is arranging a breakfast in the Technopark in Zürich.

Christian and I will hold a technical talk about Behavior Driven Development (BDD) and also present examples with SpecFlow.

The event starts at 8:00. Everybody is invited. Its free and there will be coffee and croissants. Please register here.

follow me on twitter, I need some friends :-)

Dead-End Heroes

Apart from the wonderful scottish accent there was one train of thought that particularly caught my interest in SE-Radio Episode 156: Kanban with David Anderson:

Estimation is a choice! Estimates lead to commitments that drive a dysfunction that is undesirable:

Estimates lead to setting an artificial target and forcing people to meet that. That tends to drive heroic behavior. [...] When people act heroically they stop improving [...] and they stop learning.

- David Anderson, SE Radio #156

follow me on twitter, I need some friends :-)

Phrases that should set off an alarm in every software developers brain

In software development there are some requirements that should immediately trigger all available bells in your subconscious alarming system:

This must be in real-time

The system must support historisation

The system must support multitenancy

The system must provide reports for every screen.

Usually those sentences are just mentioned as side notes or in the small print, as if they go without saying anyway and are the most evident thing in the universe.

But usually they imply a huge communication gap, that can cost buckets of money and bring wagon loads of grief.

Do you know other requirements that fall into the same category?

Update: @asztupak on twitter

It should support all features the previous system had

Update: Comments on Hacker News

follow me on twitter, I need some friends :-)

Inspiring talks

Sometimes we have to look beyond our noses. This is especially true when we are getting bogged in the trenches of corporate IT, getting lost in the big ball of mud, filling our brains with WTF from reading wagon-loads of legacy code...
Here are two inspiring talks by two brilliant minds:


"Unlearn your MBA" by David Heineimeier Hansson:




And the already classic "The Art of the Start" by Guy Kawasaki:

follow me on twitter, I need some friends :-)

Podcast: Scrum in Fixed Price Projects

In the first episode of TechTalk's podcast Christian Hassa interviews Mitch Lacey about the applicability of Scrum in fixed price projects.

They talk about common misconceptions, pitfalls and dangers and how to avoid them. Mitch also presents some patterns that worked in his experience.
The podcast is in english.

You can download the podcast directly or subscribe to the rss-feed or subscribe to the podcast in itunes.


BTW: For people living in Switzerland or Austria: This February Mitch is holding his Certified Scrum Master courses in Zürich (8.-9.03.2010) and Vienna (11.-12.03.2010).

follow me on twitter, I need some friends :-)

Scrum Master Certification in Zürich with Mitch Lacey

February 8. and 9. Mitch Lacey is running his Scrum Master Certification course in Zürich Switzerland.

If you are thinking about getting the Scrum Master Certification, I can fully recommend Mitch's course.
I did attend his course in Vienna last autumn. Those two days were very interesting, informative and never boring. Mitch really is a great teacher and story teller with a lot of practical experience.

If you are interested you can find more details and registration here.

Update: On TechTalk's Mind hosts a podcast with Mitch discussing Scrum in fix-price projects.

follow me on twitter, I need some friends :-)

Poignant statements about our profession

Jay Fields has a poignant but concise style to express his opinion.

Currently my two favorite quotes are:

We're still figuring this stuff out. All of us.

Thoughts on developer Testing

and

When no one knows what's "correct", people with confidence generally win the discussion.

Programmer Confidence and Arrogance

follow me on twitter, I need some friends :-)

Büroeröffnung TechTalk Schweiz im Technopark Zürich - Vortrag agiles Testen mit ATDD und BDD

Update 2009-11-18: Slides are published on SlideShare

My company TechTalk is officially opening its new office in Switzerland next Wednesday October 28 in Zurich's Technopark.

Christian and I will hold a technical Talk about realizing agile Testing with Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD).

Everybody is invited, entrance is free.

The talk starts at 16:30. Here is the official announcement. I would happy to see you there.

follow me on twitter, I need some friends :-)

Abstraction, Encapsulation and social Darwinism (The Antipattern of Framework- vs. Business-Programmers)

Responsibility trap number one: Building a platform to make other (lesser) programmers more productive.

- Eric Evans at SET 2008

Hiding things from developers often requires more effort in the long run than simply trying to educate your developers as to how they should properly do their job.

- Educate Developers Instead Of Protecting Them by Davy Brion

Making development "safe" for lesser skilled developers by taking choices away from developers [...] does far more to hamper the efforts of your best developers than it does to make weaker developers more productive. I'll say that there is a silver bullet(s), it's: Skill. Knowledge. Experience. Passion. Discipline.

- Jeremy Miller

Again and again I come across projects, teams and companies that misuse the concepts of Abstraction and Encapsulation to establish a two class society among the developers.

In those setups you usually find on one side a framework-team that is responsible for a supposedly productivity-boosting, supposedly well crafted framework / platform / infrastructure. On the other side you find an army of business programmers that have to use the provided framework / platform / infrastructure to actually realize business value.

Usually the framework-team members think of themselves as the gurus, the elite, the "real" programmers, while the business programmers are considered as "lesser" foot soldiers.
These attitudes are mostly shared and therefore promoted by management. Indeed the framework-programmers often have the better education and/or more technical expertise.
If the situation is really bad then the framework team does not like to mingle with the business-programmers and the worst thing is, when they are not even co-located.

I heavily oppose this setup. It is an antipattern, that prevents team enabling. Agile, self-enabling, highly-motivated teams will never evolve in such a structured and divided team setup. This is not an environment where individuals are allowed to grow, this is an environment where employees are assigned! In such an environment, people just start to not care any more: framework-developers do not really care about business value, business-developers dont't feel like being able to make a difference...

As I don't believe in the factory analogy, I don't believe there is a situation where lesser developers have to be shielded/protected by a technical framework. The time to create a patronizing framework, would be better invested in teaching and exchanging knowledge.
In my experience, if a developer is not productive, then this is usually a management failure. Simple measures like assigning another task, changing the setup, pair programming, coaching, reviews etc. would usually improve the situation. I have seen projects where this has been achieved successfully, but in the above setup, this is usually not going to happen.
And in the rare case that you are really dealing with a net negative producing programmer (NNPP), no technological solution will save you... Abstraction and Encapsulation are pillars of object-oriented design. They are intellectual constructs to tackle complexity. They are technical tools and not a mechanism to legitimate team structure.

Using engineering techniques from object-oriented design to enforce team structure and separation feels just as wrong as applying Darwin's evolution theory to human societies.

Possible remedies and counter measures for the situation are:

Eat your own dogfood: Framework-developers have to use their own framework. They have to be involved in business-programming.

Empower the business developers: Establish an environment where it is absolutely clear, that the business developers are the ones that are providing value. The framework-team has the sole purpose to enable the business-developers.

Productize the framework: Nobody is forced to use the framework. The framework-programers have to actively sell their work, the business developers can freely decide if they want to use it. (According to a disscussion with Mark Striebeck, this philosophy is very successful at Google)

Collective ownership of the code, including the framework.

follow me on twitter, I need some friends :-)

The passionate developer: I do like my profession, I don't like my job

Update 2009-09-14: There are interesting discussions of this post on hackernews. Thanks!

To only a fraction of the human race does God give the privilege of earning one’s bread doing what one would have gladly pursued free, for passion. I am very thankful.

The Mythical Man Month, p. 291

Architects, designers, and developers of corporate systems usually have little or no voice in what gets built, or how, or why. They don't sign on, they get assigned. I know that individual developers do care passionately about their work, but usually have no way to really make a difference

Why Do Enterprise Applications Suck?

I consider myself an alpha-geek. I think I have met quite some other alpha-geeks.

I tend to think that there is hardly any other group of professionals that care so much for their profession like alpha-geeks.

Regarding passion, dedication and motivation alpha-geeks are very similar to artists or master craftsmen.

Alpha-geeks usually don't (want to) make a difference between their job and their hobby:
"Tenet of professionalism: Work 40 hours for your employer and another 20 hours improving yourself." (tweet by unclebobmartin)

... at least that would be the case in an ideal world ...

In reality I have almost never met a passionate developer, that is really happy with his job.

In reality it's more likely that the alpha-geek is working the additional 20 hours, because he is frustrated with the 40 hours he had to spend for his employer... because he could not realize his ideas of real development, because he was bogged down with fabricated complexity, because he lost his way in a maze of legacy code and because he had to spend so much time and energy for bureaucratic overhead ...

This is a schizophrenic situation, and I wonder why it is so common?

Probably a lot can be credited to the Office Space clichés that can be found in corporate environments. And to the fact, that in a lot of those environments it's impossible to deliver software that matters.

But I think it's too easy to lay all the blame on corporate environments.


I think a part of this schizophrenic situation can be credited to a blame-the-others-syndrome. If things are hard and if there is friction, it's always easier to blame the others. It's only self-protection to assume the stance "If I only could do things my way, everything would be good!"

I also think software development is especially susceptible to this schizophrenia, because nowadays it almost exclusively deals with intellectual constructs. It is very easy to create a clean, wonderful notion of a perfect software system and to imagine an ideal software development process. That's because we can let our imagination run wild, since there are no real constraints in theory. At least in theory there always exists a perfect solution. That's a major difference to other (real) engineering disciplines.
It's very convenient to think that we could realize the perfect solution, if only we could do things our way...
...only in our perfect solutions we did not consider those accidental constraints like people, time, economic factors ...


A third aspect is that there are hardly any measurable characteristics in software development. Therefore personal taste, preferences and gut feelings become important. And since these are very individual, it's a logical consequence that we always have to deal with compromises when we are working with other people.


I believe that leveraging the passion and motivation of developers is a key factor for forming highly productive teams. This has been shown with different studies.
But to a certain degree this is a blade with two edges. Highly passionate developers are much more susceptible to the schizophrenia mentioned above. I think the key is to accept, that real-world software development is never perfect. Our job is it to pragmatically live with this imperfection.

follow me on twitter, I need some friends :-)

Announcement: Zühlke Blogstream Transfer

I will be leaving Zühlke at the end of August. The Zühlke Blogstream I aggregated, will be maintained by Stefan Jäger.

Stefans aggregated Google Reader URL is here.

The RSS-Feed has not changed: http://feeds.feedburner.com/zuehlke

follow me on twitter, I need some friends :-)

Balsamiq Mockups

People who are involved in user interface development should definitely check out Balsamiq Mockups. I have successfully used the free online version, and would recommend the product for any project where UI design is involved.

Everybody interested in a Web 2.0 startup success story, should also have look at Balsamiq. Read this interview and this blog post.

follow me on twitter, I need some friends :-)