Seek out feedback and learn from your mistakes as you go along

At the end of the tunnel, there is always light; It just might be a train.  

The Streets, Going through hell

The headline is a quote from the Palchinsky Principles, via Gojko Adzic's worthwhile talk "Make impacts, not software" (via @jbandi).

In May I visited the Lötschberg-Basistunnel, a recently completed 35km tunnel through the Swiss Alps. I learned two amazing things from the guide:

1. Most complex tunnel drills stay in the tunnel. It would be too expensive to get out of the tunnel (the costly heads are unmounted sometimes) – because they start plastering the inner shells right after it.
2. In the beginning it’s not really clear where the tunnel drill will take its way. As the head moves forward, rock formations can require changes in the trajectory.

Gojko Adzic merges Design Thinking, SMART objectives, architecture assumptions documentation and business case calculation into “Impact Mapping”, singing the old hymn about analysis-paralysis and Water-Scrum-Fall. He claims that pre-planned software development “it's not a road, it's a tunnel”; rather than sticking to a linear backlog, project should have “something like a GPS”, a vision. Funnily that's how, in fact, tunnels are built. Roads on the other hand often are grids. It's not the question of a tunnel or a road - the distance makes the difference. A straight planned product with tons of features in a neat grid will not enhance usability. Creating a vision – an impact that everyone understands – will.  Being able to define a long-term goal allows for adjustment. Rather than just to “divide and conquer”, this is the art of the product owner.

As someone who moved from startups and design/advertising into traditional consulting I am amused by the now-mature generation of Web 2.0 firms which start to look into the very same traditional processes: product planning, sticking to delivery, definition of requirements which are backed by business cases, business process management and simple interfaces. It's good to see that the mechanic and the organic approaches to software development finally merge, creating a mature, objective and tolerant way of building technology that helps the people using it. 

Something between Micro Services and ROA

A post from July 2013 on Microservices I never finished but now, in 2014, like to reference. It's unchanged, so take it with care and read Fowler's and Richardson's stuff first.

I've read two interesting articles recently one on Divide and Conquer and another one on Simplicity*. Both advocate a new pattern of maximum decoupled services called Micro Service Architecture (by Fred George).

...

This reminds me of NoFlo and Mathematical Visualizations and Abstractions. The strength of Micro Services is not the Continuous Deployment or Decoupling but enforcing to think about organization and the connections of functionalities, because one cannot simply tangle them.

...

However, Micro Services are still services, which means verbs. If they would be nouns, there would be no need to manage tangling because the complexity would already be in the hypermedia.

Maybe something in between is the future of Software Engineering, where Data is managed in REST but logic as Micro Services can be moved between the tiers, as horizontal view of vertical data.

....

*) The solution to this within Yammer is DropWizard, an approach going in the direction of Cell Architecture, with Autodeploy features added and a noun-based approach. A little bit like the Java answer to the 12 Factor App and Docker but, in my opinion, too much of a data expose layer with some PaaS candy.