Software architects think abstract. Sometimes too abstract which gets them associated with towers, mostly ivory ones.

What people are missing is that software architects have to think abstract. On a nitty gritty detailed level, one cannot fit an entire software system into a single head. And after all, fully understanding a system is an architect’s #1 priority.

Abstraction is dangerous. Things that work on a white board with clouds, boxes and lines do usually not work as well when put into action. Abstractions simplify, and may hide the real problem.

Project teams should accept this discrepancy rather than putting architects into towers. Architects need to be challenged in their decisions to make a really good job. Good architects make it easy and comfortable to get challenged.

I used to dream about awesome green field projects. Projects that are developing an interesting product or solution from scratch with no constraints. In short, a software developer’s dream.

In a new market, greenfield projects are certainly interesting, and necessary after all. But then there are all those attempts to replace an existing software with a total rewrite.

I’ve come to dislike “rewrite projects”.

Let’s start looking at the problem from the business side. Essentially, a rewrite is a big investment, both money and time, to get back to where one is already. With the added problem of maintaining the old software and finally the migration. The only way to justify the investment can be the better non-functional characteristics of the new software, such as:

• Increased maintainability
• Support of new business models
• Better user experience
• Higher performance
• … (you name it)

Switching over to the technical side, the immediate question becomes: Can these non-functional goodies only be achieved with a rewrite? Obviously not. In the most general sense, a software can always be re-engineered towards these goals by replacing piece by piece.

The piecemeal approach to updating existing software eliminates the problems of a rewrite, but one might argue that it is much more expensive overall and takes much longer. Really? Yes, it maybe does take longer and is more expensive if all pieces need to be replaced so that one essentially ends up with a rewritten software.

I can hardly believe, though, that it takes more time and is more expensive to reach the actual business goals!

So why do all these rewrite projects happen? I have two explanations:

It sucks! Let’s just redo it. That’s what people say when they haven’t really thought about their goals. There are negative feelings and opinions associated with the existing software, leading to the impulse to get rid of it. Often times, I believe this also comes from not completely understanding the existing software or the problems associated with it.

Software people are not educated for re-engineering. Where do software professionals learn about maintaining or even re-engineering software? I can’t see anything at colleges or other educational institutes. There is also not much written about it, and the topic is virtually absent in the community discussion. In short, software professionals are trained to write new software but not really to work with existing, possibly messed up, software.

Imagine how much value is lost in the software industry by constantly rewriting things. Sure, there are more and better assets available that make one faster doing it, but the same also applies to working with existing software.

Rewriting stuff isn’t the only way to create something remarkable. I’d be very proud about a nicely re-engineered software just as much, really even more!

Recent events made me think about what a truly agile development organization should look like. Not in a small startup, that problem seems somewhat solved, but in a mid-sized company or even a large corporation which appears to be a not-at-all solved problem.

Hierarchies are poison for anything agile because they establish boundaries and reduce the responsibility of the individual. Also, teams are a big deal in agile which brings us to an organization with just a bunch of equal teams. As the team is the only structuring element, it should reflect the primary characteristic that segments the business: products or projects or customers, are probably the most common examples.

It is my firm believe that a team should be basically unorganized. No team lead or any other form of organization or hierarchy is appropriate here. A team should just have all roles assigned to individuals, but really every role is equal. That especially applies to architects and developers!

Now, one will probably want to be the organization more than the sum of the teams. Things like tools, technology or process just need to be harmonized a bit across the teams, although generally every team should do what works for them. That requires a number of leaders who together develop and implement the organization’s vision. One of them should probably be appointed as the ultimate decision maker so that arguments can be settled quickly.

On the bottom line, the agile organization I envision is very, very simple. It’s not even a real organization; it is more a way of working together. The less organization, the better! After all, anything organized is difficult to change and designing for change is one of my most important values.

One thing is pretty sure, though: My agile way of working together is nothing for control freaks and especially nothing for traditional line managers!