Coding the Architecture - sbrown

Ikke så smidig prosjektmetode, likevel?

Mon, 09 Jan 2012 09:02:08 GMT

While with Bouvet, in addition to the digi.no interview, Simen Sommerfeldt and I were interviewed by Teknisk Ukeblad about how agile isn't a substitute for basic software engineering, architecture and craftsmanship.

Read Ikke så smidig prosjektmetode, likevel?...

Smidig må kombineres med arkitektur

Sun, 08 Jan 2012 21:17:20 GMT

I spent a fantastic few days with Bouvet in Oslo towards the end of last year where talked about software architecture with some of the team, customers and press. For the Norwegian speakers that haven't seen it, Simen Sommerfeldt and I were interviewed by digi.no about software architecture, agile and "just enough".

Read Smidig må kombineres med arkitektur...

Contextualising just enough up front design

Thu, 05 Jan 2012 22:40:41 GMT

In our move away from the waterfall way of building software, it's common for software teams to ask how much up front design they should be doing. Just enough is a good starting point but what exactly does that mean?

RE: Clean Architecture

Tue, 22 Nov 2011 23:10:04 GMT

Clean Architecture is a follow-up post by Uncle Bob to much of the recent commentary on Clean Code Episode VII - Architecture, Use Cases, and High Level Design, including my own post called The delivery mechanism is an annoying detail. I'll keep this short because I only want to pick up on a couple of points. Uncle Bob says...

In the weeks since I started talking about the need to clean up our architecture, I’ve noticed a surprising resistance to the idea. Apparently the notion that it’s a good idea to hide the framework, UI, or database from the application code is not universally accepted.

I'm 100% behind the idea of keeping architectures clean and (as far as possible) decoupling the application code from the technology choices. I even mention "Boundary, Controller, Entity" in my The Frustrated Architect talk (video available) as a good way to decouple. I mean, why would you want to start a web server or database just to run some unit tests? That's crazy.

One somewhat dissenting view, written by The Frustrated Architect in his coding {the} architecture blog is here. He shows a picture, which I’ll repeat:

... see picture below ...

The point he’s trying to make is that if the UI and Database are a much larger part of the system than the business rules, then the architecture of the system should be more oriented around those larger elements. Of course I disagree. No matter how large any one part of the system is, the other parts should be decoupled from it.

No, that's not the point I'm trying to make. I'm saying the delivery mechanism is NOT an annoying detail that can be deferred or ignored "right off the end of the world". I'm going to quote myself here from The delivery mechanism is an annoying detail...

That's right, the annoying detail is actually a large chunk of the system and, for me, architecture is about more than just what's contained within "the application". Structure is very important, but what about that tricky stuff like non-functional requirements, the actual delivery mechanism (technologies, frameworks, tools, APIs, etc), infrastructure services (e.g. logging, exception handling, configuration, etc), integration services (internal and external), satisfying any environmental constraints (e.g. operations and support), etc. For me, this is what "architecture" is all about and *that's* "the whole enchilada".

I consider the role of the software architect to be about looking after the big picture and the type of decoupling that Uncle Bob talks about is exactly the sort of architectural principle that I would adopt on my projects. However, in this role as a software architect, I'd be foolish to ignore the other major factors that may cause my project to fail. This includes, but is not limited to, all of the stuff that I quote above (tricky non-functional requirements, etc). A good software architecture is not just about clean code.

The executive summary

Again, to recap in case I'm not being clear...

Decoupling application code from technology is good and certainly something we should all strive for. The result is code that is easy to unit test, easy to substitute, easy to maintain, easy to change, etc.
Software architecture is about the big picture and application code is only one part of that big picture.
You run the risk of your software project failing if you continually defer significant decisions about the "delivery mechanism" and don't consider how to address your significant non-functional requirements and/or constraints.

To summarise points 2 and 3 ... the delivery mechanism is not an annoying detail. Now, please go back and read Clean Architecture from the "Not Rocket Science" section because there's some really good advice in there. :-)

The Frustrated Architect - video and slides

Wed, 16 Nov 2011 23:40:00 GMT

A really short note to say that the video and slides from my "The Frustrated Architect" talk at Skills Matter yesterday evening are now all available online. Here are the links...

Abstract and slides (online view and downloadable PDF)

Video

I really enjoyed presenting this session but the discussion afterwards in the pub was fantastic. Seems like others are running into similar problems on some of their projects, so maybe the advice I give in the talk will be of use to you too. :-)

The delivery mechanism is an annoying detail

Sun, 06 Nov 2011 20:16:02 GMT

In my The Frustrated Architect presentation at GOTO Aarhus in October^*, I talked about how there are a number of "classic" software design techniques from the pre-agile era that are being used less and less. For example, things like UML, class-responsibility-collaboration cards and component-based design. This is a shame because some of these techniques can complement an agile way of working and would perhaps prevent some wheels from being reinvented. If people don't know about these techniques though, how will they adopt them? I'll come back to this shortly but, first, I was intrigued by this tweet from Uncle Bob a few weeks back.

I don't necessarily disagree with this statement, although I like to see a software architecture grounded in reality, and that includes technology choices. Another tweet from Uncle Bob...

Again ... maybe, maybe not. Surely if there are some key technology choices that need to be made, then they should be made, right? Finally, another tweet...

Hmmm, if I don't or can't defer decisions, does this mean that I have a bad architecture? Shouldn't deferral be a conscious decision rather than a rule? All of this and the discussion that followed on Twitter intrigued me enough to stump up the cash for Clean Code Episode VII - Architecture, Use Cases, and High Level Design to see what Uncle Bob's perspective on architecture is.

Clean Code Episode VII - Architecture, Use Cases, and High Level Design

Now that I've watched it, what do I think? Well I'm really pleased to see coverage of a couple of things. The first is describing functionality through delivery mechanism independent use cases, where there is no discussion of web pages, screens, buttons, technology, etc. And the second is the follow-up technique where you decompose a use case down into a number of different classes, each of which has a distinct responsibility. These are entities (e.g. business objects), controllers (also known as interactors, which represent the actual flow of control described in the use cases) and boundaries (which represent an interaction with an actor through the "delivery mechanism"). What these techniques basically do is allow you to describe and implement a use case in a way that is completely independent from the way that the use case will be delivered. In effect, you can bolt-on a number of different delivery mechanisms (e.g. a web or console app) without changing the actual core of "the application", which is ultimately the functionality that is being described by the use cases. As I said at the start of this post, these are the sort of techniques that many people don't know about, so I'm really pleased to see them being communicated here.

I'm in agreement then?

Coming back to Uncle Bob's tweets, I can now see his perspective. Adopting this approach does allow you to defer technology decisions and from the perspective of the use cases, this technology stuff is really just an "annoying detail".

I agree that the boundary-controller-entity technique is a great way to design software because the result is a really nice separation of concerns, which ultimately leads to something that can be easily unit tested and extended in the future. This is all about partitioning and isolation. OK, so I'm agreeing with Uncle Bob then? Hmm, not quite.

"Architecture"

Throughout the video, Uncle Bob says the following (which I've paraphrased).

The architecture of an accounting app should scream accounting. A web and console version of the same accounting app should have identical architectures. The web delivery mechanism is a detail.

This is repeated a number of times through the video and it's based upon all of the good stuff that I've talked about above. However, I find myself in strong disagreement with the message as a whole. And here's why ... because the word "architecture" is being used. At face value this might sound pedantic but let's consider for a moment what Uncle Bob is actually talking about by redrawing the above diagram. Let's imagine that you're building an accounting app that you want to deliver over the web. Security is important so let's break it into multiple physical tiers. And we need to store all of the accounting data somewhere, so let's use a database. How does that annoying detail look now then...

That's right, the annoying detail is actually a large chunk of the system and, for me, architecture is about more than just what's contained within "the application". Structure is very important, but what about that tricky stuff like non-functional requirements, the actual delivery mechanism (technologies, frameworks, tools, APIs, etc), infrastructure services (e.g. logging, exception handling, configuration, etc), integration services (internal and external), satisfying any environmental constraints (e.g. operations and support), etc. For me, this is what "architecture" is all about and *that's* "the whole enchilada".

^*I'll be presenting The Frustrated Architect at Skills Matter in London on the 15th of November and you can sign-up for free

Update

If you don't have the video but want to get a feel for Uncle Bob's approach to architecture, take a look at the following links...

Architecture Deference (<2 minute video)
Screaming Architecture

GOTO Aarhus 2011 and Software Architect 2011

Thu, 06 Oct 2011 10:56:30 GMT

Conference season is again upon us and I'm speaking at two events over the next couple of weeks.

GOTO Aarhus 2011

I'm presenting a session at the GOTO conference in Aarhus, Denmark called The Frustrated Architect that will look at the role of the software architect in today's world of modern software development. I'll be focussing on perceptions of the role, how agile has positively and negatively affected software architecture, some of my pet peeves with people that call themselves "software architects" as well as my own frustrations with the role. To end on a high note, we'll finish off by looking at how you can undertake the role in a lightweight and effective way. There's some other stuff in there too but you'll have to wait for that. ;-)

Software Architect 2011

The week after I'll be in London for the Software Architect conference where I'll be presenting two one-day workshops ("Software architecture in a day" and "Just enough up front design") and three 90 minute breakout sessions ("Effective sketches", "Software Project SOS" and "How much is just enough?"). All of these follow the same theme in looking at how software architecture fits into the new shiny agile world that we now live in.

Evernote slide packs will be available for all of these sessions and I'll post the URLs (here and on Twitter) 1-2 days before each session. Should be an excellent couple of weeks.

Effective Sketches at Skills Matter

Fri, 02 Sep 2011 06:40:56 GMT

I presented my "Effective Sketches" talk last night at Skills Matter where we looked at how to produce effective diagrammatic representations of software systems and why they are useful. In other words, we looked at how to draw boxes and lines. :-)

Here are the links to the slides and video.

Evernote version of the slides (~34MB; see Using Evernote for training courses for information about what this is all about)
PDF version of the slides (~85MB)
Online view of the slides
Video of the talk

If you missed the talk, I'll be doing a slightly longer version at the upcoming Software Architect 2011 conference, which takes place in London during October.

Using Evernote for training courses

Sat, 27 Aug 2011 11:57:54 GMT

There's been some interesting discussion on Twitter recently about whether trainers should provide handouts before training, after training or even at all. Some organisations that I train through do provide printed slide handouts and some don't. My preference is to not provide attendees with printed handouts of the slides because it just seems excessive from an environmental perspective, but I am happy to provide a PDF copy of the slides instead. The downside of PDF slides is that taking notes related to a particular slide is somewhat trickier than it needs to be. So, I want to try something for my upcoming Software Architecture for Developers training courses ... Evernote; a cross-platform notebook application.

In addition to the PDF copy of the slides, I'll also be providing an Evernote XML Format file (.enex) that you can import into your own copy of Evernote on your PC or Mac. This contains all of the slides that I'll be using along with the handouts that are required for the case study exercises. You can add your own notes to each slide and create new notes to store photos of the case study exercises, thoughts and useful links as we progress through the course.

Evernote is free to download and you'll need to register for a free account, which is all you need for a local (non-cloud based) notebook. Premium account holders will be able to import the notes into a cloud-based notebook and have it synced to all of their other Evernote devices^*. If you're coming along to one of my training courses over the next few months, please do feel free to bring your laptop. I'll also be doing the same for my upcoming presentations for the rest of the year and will provide the .enex files in advance.

^* you do get syncing with the free account, but the size of the notebook is slightly larger than the monthly usage allowance :-)

28th August 2011: since each Evernote note can have a "source URL", each note in the notebook will additionally have a link to the associated essay from our book for further reading after the course.

Load Testing for Developers

Thu, 25 Aug 2011 20:43:59 GMT

September sees me picking up the travel baton again and one of the things I'm doing is a half-day session at the Skills Matter Progressive .NET Tutorials in London on the 6th.

The session is called Load Testing for Developers and it's exactly what it says on the tin ... an introduction to load testing for developers. You can be as progressive as you like with the .NET platform, but performance and scalability problems can still rear their ugly heads regardless of the technology you're using.

Have you ever built a software system and your users have complained that it’s too slow? I have; debugging live performance and scalability issues with business sponsors watching over your shoulder isn’t fun! Load testing is an often forgotten and seemingly difficult task that many people shy away from but a basic level of load testing is often enough to give you confidence that you've satisfied expectations regarding performance and scalability. This tutorial will look at how to load test your website and you’ll learn:

What load testing is all about.

How to implement a load testing script using the free and open source Apache JMeter tool.

How to run a load test and monitor the environment (the load testing client and your website server environment).

How to process, analyse and present the results.

The tutorial is a mix of presentation, discussion and hands-on exercises where we'll be looking at some of the theory behind load testing before trying it out with Apache JMeter. Specifically, we will:

Create a basic test plan using the proxy feature of JMeter.
Clean-up the test plan plan and make it work for a single user.
Add some test assertions, as you would when unit testing.
Modify the test plan to work for a number of concurrent users.
Run the plan in JMeter headless mode.
Parameterise the number of threads (users), website hostname and port.
Modify the plan to make it more realistic (e.g. simulating user think time).
Execute the tests and capture the results data.
Process the results and draw conclusions.

Software

If you're coming along and want to participate in the hands-on exercises, you'll need the following installed on your laptop:

Microsoft Visual Studio (2008 or 2010; to run a C#/ASP.NET 3.5 web application).
Java SE Development Kit (version 6 or 7).
Apache JMeter 2.5 (download the ZIP version and unzip it somewhere obvious).
Evernote (optional; if you want the enhanced slide pack).

Material

Here are links to download the material we'll be using in the tutorial.

Load testing ~~is a natural extension to~~ should be part of the developer or architect role if you're building web applications and not something that should be left until the very end of the software development lifecycle. Come along if you want to find out how easy load testing can be.