The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links



Post Categories

Thinking outside of the box

There is no such thing as technical debt
Ward Cunningham coined the “technical debt” metaphor. It sounds plausible, it might resonate with management. But it’s far from reality. Let’s think about financial debt for a moment. How do you get indebted? With a financial debt it’s crystal clear when you get into it. You go to a bank and ask for money. That’s a very clear cut moment in your life. The amount of money you owe somebody is crystal clear to you and the creditor. How much you pay for a credit is crystal clear to you and the creditor. ......

Posted On Wednesday, July 22, 2015 10:35 AM | Comments (43) | Filed Under [ Thinking outside of the box ]

The IODA Architecture
The common architectural patterns are all pretty much the same. Layered architecture, MVC, Hexagonal architecture, Onion Architecture, Clean architecture… they all do two things: Define domains of responsibility Put functional dependencies in order Look at these depictions of some of the patterns: What you find are shapes (rectangles, circles) with the responsibility to produce part of the required behavior of a software. All models forsee certain responsibilities like interaction with the user, ......

Posted On Wednesday, April 29, 2015 3:15 PM | Comments (10) | Filed Under [ Thinking outside of the box Software architecture ]

Sweet Aspects
When a module has a single responsibility that means it’s focused on producing the behavior of a single aspect. That’s how I described the Single Responsibility Principle (SRP) in my previous article. Since the SRP is so important and at the same time a bit elusive, I thought, I try to illustrate this “traits and aspects thing” a bit more. Maybe you can even develop a taste for the SRP :-) Look at this heap of sweets: Let them represent logic in your code. You know, those 5,000 lines of code in a ......

Posted On Monday, April 27, 2015 8:59 PM | Comments (0) | Filed Under [ Thinking outside of the box Software architecture ]

The Single Responsibility Principle under the microscope
It’s equally important and mysterious: the Single Responsibility Principle (SRP). And even though its originator Robert C. Martin tried to explain it again, I feel there is something lacking. Some concreteness, some tangibility. First the definition of the SRP in Martin’s own words: “The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.” This is more informative than Wikipedia’s tautology: “In object-oriented programming, the single ......

Posted On Saturday, April 25, 2015 5:47 PM | Comments (1) | Filed Under [ Thinking outside of the box Software design ]

In need of more abstraction
The ultimate product of software development is this: CPU executable binary code. Decades ago we used to “write” this more or less directly into memory. But that was very tedious and error prone. Code was hard to reason about, hard to change. Abstractions in code So we looked for ways to make coding easier. Enter a higher level of abstraction: Assembler. By representing machine code instructions as text and throwing in macros productivity increased. It was easier to read programs, easier to think ......

Posted On Wednesday, December 31, 2014 12:39 PM | Comments (1) | Filed Under [ Thinking outside of the box Software modelling ]

Feedback-Centric Development - The One Hacker Way
Erik Meijer got something right in his talk "One Hacker Way". There's a lot of bashing and ranting... but at the core there also is a precious diamond to be found. It's his admonition to be driven by feedback. As software developer we should focus on production code - and let ourselves be guided by feedback. How true! How simple! But contrary to the audience's belief it's no easy feat. He got much applause when he suggested, attendees who had not committed code recently should leave. People liked ......

Posted On Sunday, November 16, 2014 10:22 PM | Comments (2) | Filed Under [ Thinking outside of the box ]

There´s no #antifragilesoftware
Antifragility has attracted some attention lately. I, too, pressed the “I like” button. :-) A cool concept, a term that was missing. Just when Agility starts to become lame, Antifragility takes over the torch to carry on the light of change… ;-) What I find sad, though, is that the discussion seems to be too technical too soon. There´s the twitter hash tag #antifragilesoftware for example. It´s suggesting, there are tools and technologies and methods, to make software antifragile. But that´s impossible, ......

Posted On Thursday, March 13, 2014 11:19 PM | Comments (3) | Filed Under [ Thinking outside of the box ]

What does Antifragility mean?
The notion of Antifragility has hit the software community, it seems. Russ Miles has posted a couple of small articles on it in his blog, asking what it could mean for software development – but also listing a couple of ingrediences he thinks are needed. I´ve read the canonical book on antifragility by Nassim Taleb, too. And I second Russ´ description: Antifragile software is software “that thrives on the unknown and change”. But still… what does it mean? “To thrive on the unknown and change” to ......

Posted On Wednesday, March 5, 2014 9:28 PM | Comments (1) | Filed Under [ Thinking outside of the box ]

Recursively descending test-driven development aided by thinking
“Hey, Ron, wanna try something new”, Janine asked across the table in their team room. Ron looked at her uneasily over his line of monitors. For hours he had been trying to fix this elusive bug. “Nah, not now. I really need to get this done first, Jan.” “Oh, come on, Ron, that´s what you´re telling us all the time.” Ron blushed. That certainly wasn´t true. Especially not with regard to Janine. “You know me better than that, Jan. I´m always willing to help you out and stuff. But right now…” “It won´t ......

Posted On Monday, February 10, 2014 9:29 PM | Comments (0) | Filed Under [ Thinking outside of the box Informed TDD ]

The Self-Similar Software Development Process
I read, with interest, Robert C. Martin´s comment on Justin Searl´s critique of a common TDD teaching approach. Strange it was to see “the good uncle” to be so upset about Justin´s article. Why does he take it so personally, it seems, that someone is not content with the state of TDD-affairs? Why salting Justin´s earth? Anyway… what I wanted to express is my disagreement with Robert C. Martin´s idea of a “Domain Discontinuity”. He proposes there to be two levels in software system design: one, where ......

Posted On Friday, January 31, 2014 8:00 PM | Comments (14) | Filed Under [ Thinking outside of the box Software design Informed TDD ]

Get into the flow with Spinning
Spinning as described in my previous article is all about flow. Its premise is: flow can emerge when work is partitioned in small, evenly sized chunks processed in a smooth manner. There is a constant input of requests to the development team. A backlog is filled with strategically important requirements, support is reporting bugs, feedback requires changes, management wants to see ideas realized on short notice. Under these circumstances any plan becomes obsolete within a day or two. Or a lot of ......

Posted On Friday, December 23, 2011 1:55 PM | Comments (6) | Filed Under [ Thinking outside of the box Spinning ]

Spinning – Getting Agile at the Core
Agility needs to get onto the next level – that´s what I tried to explain in my previous articles. After a reality check – what´s missing from Agile practice? –, and some general musings about how a next level of Agility could look like, here now some very tangible suggestions. Crank up the frequency Current Agile practice is suffering from too little attention to Acceptance. To change this, very, very clear Acceptance dates need to be set. Acceptance can only get into a real pulling mode, if dates ......

Posted On Thursday, December 22, 2011 10:49 AM | Comments (2) | Filed Under [ Thinking outside of the box Spinning ]

From Agile to Elastic
In my previous article I came to a couple of conclusions based on the reality of software development, or should I say “the nature of software development”? Here are the – to me - undeniable facts of what our industry is all about: Customers hardly know, what they want. Any specification is inherently fuzzy and incomplete. What fits the customer´s needs can only be determined by actually trying it out. The customer can only recognize a running piece of software as acceptable. Because customers hardly ......

Posted On Friday, December 16, 2011 2:19 PM | Comments (2) | Filed Under [ Thinking outside of the box Spinning ]

Agile Process Reality Check
Let´s get real about software development: It´s never going to be a quietly flowing river. Never. And that´s why the current approaches to software development like XP, Scrum, and Kanban will always cause pain. Their basic assumption is you should be able to isolate a team for a while to work on features. Leave it alone during an iteration or a sprint to complete a set of features, or at least sit still until the current feature is done. Certainly that´s what we all want as developers: being able ......

Posted On Wednesday, December 14, 2011 2:22 PM | Comments (13) | Filed Under [ Thinking outside of the box Spinning ]

AppKata - Enter the next level of programming exercises
Doing CodeKatas is all the rage lately. That´s great since widely accepted exercises are important to further the art. They provide a means of communication across platforms and allow to compare results which is part of any deliberate practice. But CodeKatas suffer from their size. They are intentionally small, so they can be done again and again. Repetition helps to build habit and to dig deeper. Over time ever new nuances of the problem or one´s approach become visible. On the other hand, though, ......

Posted On Saturday, June 25, 2011 3:32 PM | Comments (3) | Filed Under [ Thinking outside of the box ]

Thou shalt not put code on a piedestal - Code is a tool, no more, no less
“Write great code and everything else becomes easier” is what Paul Pagel believes in. That´s his version of an adage by Brian Marick he cites: “treat code as an end, not just a means.” And he concludes: “My post-Agile world is software craftsmanship.” I wonder, if that´s really the way to go. Will “simply” writing great code lead the software industry into the light? He´s alluding to the philosopher Kant who proposed, a human beings should never be treated as a means, but always as an end. But should ......

Posted On Saturday, January 8, 2011 11:31 AM | Comments (0) | Filed Under [ Thinking outside of the box ]

Powered by: