Change.

Yesterday, a software engineer, also new to the organization, roughly told me the following. The way the organisation plans projects is so different to what he is used to as a software engineer. Planning projects with a horizon of 12 or even 24 months is something he says he just cannot wrap his head around.

While this is very common and necessary in the hardware industry, it is indeed something terribly alienating software people. Software is typically treated as a living product, that takes tiny changes at a time, it is more governed towards a direction to take than having the one exact goal it has to hit by a specific date.

These very fundamental goals both mindsets follow make it difficult for change to happen. While the software engineer above obviously has a point to make, he cannot reach the people he needs to reach, because both sides are just too far apart.

At the same time, I don’t yet have an answer to the problem, but the problem itself became so obvious when this colleague told me he just doesn’t know what to say. The digital world does not yet have a common language, not to mention a common way to think about approaching problems, and unless this hurdle is taken, change will only happen slowly.

Linux at 25: Why It Flourished While Others Fizzled

Linux, the open source operating system that virtually powers all of webservers, billions of Android phones as it’s kernel just as well as the majority of home routers and IoT devices, turns 25 years this year. IEEE Spectrum runs an article on the history and why the open kernel became so successful.

Timing, cost, and the right license made all the difference.

Also, Linus Torvalds has an approach that would be called agile these days. Bringing a feature in place is more important than having the 100% solution, and Linus explains this approach in the accompanying Q&A session:

I’d rather make a decision that turns out to be wrong later than waffle about possible alternatives for too long.

via: Linux at 25: Why It Flourished While Others Fizzled – IEEE Spectrum

When a Project dies

When is a project dead?

One question that somebody asked me a few days back keeps me thinking for a while now. Mostly, because it should not have a clear answer. Have you ever had to ask yourself, what to do when your heart-project is at risk to coHantelnme to an end? A project that just dies, has had some serious problems.  A dead-end, that leaves no next steps, along a final decision. In a way that no project goal materialized and no other milestone is reachable? If that is looming to happen, one should consider to check the project plan and answer a couple of questions about the failure. How did all the tasks and work packages depend on each other, that they made an entire project fail? Were some assumptions to optimistic? Was budget too tight? Was the project to ambitious?

The show must go on

KabelDepending on size, no project is barely ever dead. Typically, a project consists of multiple components. Milestones, Tasks, Work-Packages, are just common terms for break downs structures of a project. Such fragments, re-used or re-arranged, can help achieving a modified goal. There are reasons, one or another milestone had difficulties. There are hard facts, like budgets, technical dependencies or necessities, required skills, availability of material or combinations of anything. And there are soft facts, like project team engagement, stakeholder opinion, even hubris may result in milestones not being reached.

Failure

A roadblock, identified early enough, allows to realign a project plan, to cope with any trouble, endangering tasks and milestones. In an iterative project approach, the project lead can change a goal, aligning with changing requirements. This way, the project may not reach it’s initially intended goal, but it will not fail in its totality. When a project dies, it will leave bad feelings with the budget owner, with stakeholder and the team. A goal that the team reached, maybe through a more creative approach, will still be a goal reached.

Travis CI: Continuous Integration mit GitHub

Travis CI bietet einen gehosteten “Continuous Integration” Service. Nach eigener Aussage für die Open Source Community, was sich sehr schön in der unterstützten Software zeigt. Für die Programmiersprachen C, C++, Clojure, Erlang, Groovy, Haskell, Java, Javascript mit Node.js, Perl, PHP, Python, Ruby und Scala wird eine Umgebung geboten, in die sich auch Pakete nachinstallieren und Abhängigkeiten erfüllen lassen. Continue reading “Travis CI: Continuous Integration mit GitHub”