What is Software Architecture?

The other day I got a nice LinkedIn email from graduate student asking me if architecture can evolve from continuous refactoring. There were a couple of questions about where it worked and where it didn’t, and I started wondering what was really meant by “software architecture”. Well, at the bottom of the email was RUPs definition of software architecture:

“The set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements, the composition of these elements into progressively larger subsystems, the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition.”

WTF? What does that mean? What are they trying to say? That architecture is everything? If architecture is the significant decisions, what are the insignificant decisions?

More

Start Paying your Technical Debt – The Mikado Method

[at http://mikadomethod.wordpress.com/ we will put more information on the Mikado Method]

A couple of years ago, Ola Ellnestam and I was working on a project where the code was a big ball of mud, or at least well on the way there. Global variables and singletons all across the code base, circular dependencies, deep and fragile inheritance hierarchies etc. The Technical Debt was everywhere.

Copy’n’paste?

All of a sudden we were supposed to deliver to a new client and the interest on our loan went through the roof. The reptile response from several developers on the team was to copy most parts of the code base to a new project and modify the code there. This would double our debt, but decrease the interest temporarily, until the next client would drop in. We fought with all we got to avoid doubling our debt and in the end we had convinced everybody that we could re-factor the code-base, just give us a week or two…

More

Elastic-, plastic- and fracture characteristics of code

I recently had a post about technical debt, and Jelena made a very insightful comment that it was like elastic, plastic and fracture characteristics of materials like steel. I started to comment on the comment, but eventually I thought it deserved its own post. More

User-Guide-Driven Development

In my work with Bumblebee I use an approach I call “User-Guide-Driven Development”, or UGDD for short. The mechanics of UGDD is similar to that of Test-Driven Development (TDD), but before I write the test for a feature, I write a snippet of the user guide describing the feature I am about to implement. More