Technical Design Tradeoffs

Development teams should not think of it as making technical design decisions but managing tradeoffs. There is no optimal decision and the tradeoff does not automatically lead to technical debt.

duplicate/modify vs generalize/specialize is a tough set of tradeoffa

— Kent Beck (@KentBeck) 10. Dezember 2014

Why Deployment Freezes Don't Prevent Outages

Think about this, every time you say "Never touch a running system!":

"Every running system is a ticking timebomb" http://t.co/FcFFyqTIlf Words of peace and joy.

— Kent Beck (@KentBeck) 27. Dezember 2014

The Tyranny of the Ever Decreasing Timebox

A classic reference, a must have read in Agile Development: The Tyranny of the Ever Decreasing Timebox - David J Anderson

ThoughtWorks Technology Radar

ThoughtWorks has started a monthly review on technologies: Platform, Frameworks etc.
The PDF format is perfect! Technology Radar PDF

Latest version of ThoughtWorks technology radar is out today. Themes: devops, data platforms and security tools http://t.co/FJviOIF267

— Martin Fowler (@martinfowler) 17. Dezember 2014

Problem Altsoftware

Der folgende Zitat aus dem Artikel fasst das Problem "Altsoftware" sehr gut zusammen:
"Die unterschiedlichen Web-Apps ermöglichen den Einsatz verschiedener Technologien innerhalb des Java-Universums. Wirklich genutzt wurde dies jedoch nicht. Im Gegenteil: Bewährtes wurde gerne wieder verwendet und übergreifende Konzepte in geteilten Bibliotheken hinterlegt. Eine zunehmend enge Verzahnung war das Ergebnis. Kleine Änderungen wurden aufwändig. Innovationen, wie z. B. eine Java-8-Einführung oder ein Spring-4-Update, erzeugen viel zu hohe Aufwände. Solche Themen dann zeitnah oder „nebenbei“ anzugehen, fällt nahezu aus. Unzufriedenheit über die veraltete Software und ein Verlust an „Spaß bei der Arbeit“ sind die subtilen wie ernstzunehmenden Konsequenzen.

Darüber hinaus traten weitere Symptome monolithischer Anwendungen auf: Eine technisch enge Kopplung von fachlich entkoppelten Themen resultiert in steigenden Lern- und Einarbeitungskurven bei den Entwicklern. Die Konsequenzen einer Änderung abzusehen wurde stetig schwieriger. "

Microservices

Folien zu einen gelungenem Vortrag über Microservices in München: https://speakerdeck.com/timmo/nie-wieder-monolithen-ein-praxisbericht-uber-micro-services

#ThinkingTools: The Mighty difference between #Management and #Leadership - illustrated! #WarrenBennis #beta #stoos pic.twitter.com/JnEmZc6rHm

— Niels Pflaeging (@NielsPflaeging) 9. August 2014

Seen on Twitter

Feeling agile today. pic.twitter.com/BIq6AeBRo8

— Chris Francis.js (@chrisfrancis27) 28. Juni 2013

Spotify Engineering Culture

Here’s a short animated video describing Spotify's engineering culture.
http://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

The Lean Mindset

I have visited THE workshop on Lean Mindset and Lean Software Development.
http://synchronit.com:8080/workshopRegistration/

The 7 principles of Lean along with many stories and book references can be found here:
http://www.poppendieck.com/

Thanks to SynchronIT for the great organization and location:
http://synchronit.com/

SOA Manifesto

I have signed the SOA Manifesto. I think it is the right thing to do:

http://www.soa-manifesto.org/

Kanban Values

A new article on Kanban I have seen on the blog of Dr. Arne Roock of the IT-Agile GmbH. Dr. Arne Roock translated the article in german:

"Introducing Kanban through its values"

• Original Version
• German Version

Background information: Dr. Arne Roock is well known for his participation of the german translation of the book "Kanban" by David J. Anderson.

Being Assertive

I thought about calling assertiveness the golden hammer in management, leadership and teamwork but that is pure exageration. If you do not like to work with people at all then forget it. The ability to be assertive should only be applied by people who strife in a team for a common goal.

Assertiveness is a social and communication skill that summarizes everything we want on us and others in our environment. Especially in IT projects. It is a term formed by psychology, communications and anthropology.

Nice article on being assertive: Skills you need
More articles: Assertiveness

After reading several books about agile Processes, Teamwork, Communication, Management and Work, I realized that assertiveness pretty summarizes all you need in one term. Start of Disclaimer - A master of assertiveness should be able to achieve any goal and assertive people are successfull people. - End of Disclaimer.

The problem is the high entry barrier in being assertive. It is comparable to pursue the way of buddha in enlightement. You can pursue it your whole life and still end up as a cow in the middle of nowhere in your next life.

Tools in Software Development

What you should have used inside your processes:

• Continuous Integration -> Jenkins, Bamboo 
• Dependency Management -> Maven, Gradle
• Test Driven Development (TDD) -> Arquilian, Mockito, TestNG
• Documentation -> Maven Sites, Gradle Sites, Confluence
• Build Management -> Maven, Gradle
• Ticket-/Issue/Taskmanagement -> Jira
• Source Code Version Management -> Git, Subversion, Git-Stash
• Code Review ->Crucible

Yes, I Kanban!

I think I have not mentioned it before. But well, Yes, I Kanban. I like that slogan :) I mean I do software Kanban. Kanban is a methodic in mass production. Mass production is a discipline in production management. I think its the perfect buzz word and people want to imply some things.

First of all Kanban kind of rescued the automobile industry. So it will be able to rescue your software development, or? Secondly, it implies that software can be mass produced which is just wrong. So forget that and stick to the virtues of Software Kanban.

How does Software Kanban work? Follow this comic "One Day in Kanban Land".

Do not be misled by the buzz word, Kanban is not just buzz. Kanban is one of many software development methodologies. It can be aligned or combinated with Scrum and Xtreme Programming. It is higly adaptable and can be easily applied to new and running projects. It is considered as the entry stone to agile development.

It belongs in your tool box.

Getting frustrated with IDE´s

Working with eclipse never seemed so cumbersome. A bunch of plugins which seem to behave in an arbitrary and non comprehensible way. It´s even getting worse from release to release and installation. Is there something better?

Along my career I used several IDE´s. Starting from old DOS txt file editing to current eclipse or myeclipse IDE:

• DOS console text file editing. 
• WJed text file editing with syntax highlighting.
• JBuilder IDE.
• Eclipse 2.x  until Indigo.

Sure, demands are getting complex:

• Versionmanagement. (Subversion Plugin)
• Build-Management. (Maven Plugin)
• Faceted Projects (Web application, EE applications, Persistence, etc.)
• Annotations (Hibernate,JAXB,Dozer tools plugin)

But, I begin to doubt the eclipse implementation. Eclipse costs me dearly. Eclipse uses too much time for configuration and reconfiguration. Worse; Sometimes the workspace "breaks-down" even irreparable.

Yes, Eclipse is free. No, I don´t like it anymore. I am looking for alternatives. The first try of IntelliJ already made me think:

1. Is the eclipse IDE at its final end when it comes to productivity? 
2. Should we waste production time and efficiency for a free tool? 

Alternatives:

• IntelliJ IDEA
• Netbeans
• Cloud/Browser-based IDEs. (e.g. Cloud9)

I´m ready for a change, what about you?

Quick-Learning Programming Languages

Web tutorials for several programming languages. Can be performed online without any installation. It's fun and it certainly shares some enlightenment:

• Ruby: http://tryruby.org/levels/1/challenges/0
• Go: http://tour.golang.org/#1
• Scala: http://www.simplyscala.com/
• Python: http://people.csail.mit.edu/pgbovine/python/tutor.html#mode=edit

Processes in Software Development

What you should have implemented:

• Continuous Integration
• Configuration Mmanagement
• Test Driven Development (TDD)
• Documentation
• Build Management
• Ticket-/Issue/Taskmanagement
• Version Management
• Code Review

What You Should Know As A Software Professional

Have you ever wondered what you should know to name yourself a software developer? From the book Clean Coder:

• Design patterns. You ought to be able to describe all 24 patterns in the GOF book and have working knowledge of many of the patterns in the POSA books.
• Design principles. You should know the SOLID principles and have a good understanding of the component principles.
• Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design.
• Disciplines. You should practise TDD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming.
• Artifacts: You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.

Sounds pretty much but distributed in a 20 year career its a pretty reasonable career plan. What's harder:

1. Being able to apply the knowledge in your local work environment.
2. Being able to remember it. I usually tend to forget most design patterns in a matter of months.

Innovation

Recently...

I encounter the word "innovation" more and more often. Where does it comes from? Who propagates this term currently?

Please, bear in mind: Innovation is a necessity, no solution for problems!

Only introduce and define innovation in a healthy IT environment.