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.

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.

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:

1. Create a basic test plan using the proxy feature of JMeter.
2. Clean-up the test plan plan and make it work for a single user.
3. Add some test assertions, as you would when unit testing.
4. Modify the test plan to work for a number of concurrent users.
5. Run the plan in JMeter headless mode.
6. Parameterise the number of threads (users), website hostname and port.
7. Modify the plan to make it more realistic (e.g. simulating user think time).
8. Execute the tests and capture the results data.
9. 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.

• Slides (online view)
• Slides (PDF; 8MB)
• Enhanced slide pack (Evernote format; 20MB)
• ASP.NET web app (Visual Studio solution)

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.

There's a great blog entry over on the SATURN Network Blog entitled Software Architecture and "The Principle of Small Decisions" that talks about how even those small day-to-day decisions can cause havoc if you don't keep on top of them.

inattention to the small decisions can cause problems ... many decisions made at the individual level can end up having broad system impact

I'm in agreement and it's worth bearing in mind that not all day-to-day decisions will be "architectural" in nature. Yes, software architecture is about the significant decisions, but the software architecture role is needed on an ongoing basis throughout the entire project to ensure that decisions made complement the architectural vision rather than fight it. If you have enough of these small decisions waiting to be solved or solved poorly (perhaps because software development has been treated like a relay sport), you have what the SATURN Network Blog refers to as "landmines in the code".

Imagine you need to build a road from A to B, which will need to cross a number of different terrains and environments. After figuring out the overall route at a high-level (the significant decisions), you're left with the day-to-day decisions related to much smaller sections. Assuming that the overall route is correct, failure to address the day-to-day issues properly can result in a road that ultimately ends up being littered with potholes, traffic cones and debris. Sure, the road might look good from the 30,000 ft view and it might even get you from A to B, but we all know that the journey will be a bumpy ride.

People often joke about how software architecture is just about boxes and lines; and while this is true to some extent, being able to draw pictures doesn't make you a software architect. Pictures *are* invaluable during the entirety of the software development process but actually producing decent pictures is a skill in its own right, so much so that we spend some time talking about and practicing it on our 2-day Software Architecture for Developers training course.

 

 

I'll be presenting a session called "Effective Sketches" at Skills Matter (Thursday 1st September) and the Software Architect 2011 conference (Wednesday 19th October) where I'll be exploring this topic in more detail. Here's the abstract...

The code might be the architecture but at some point in time you’re going to have to explain how it works, and that’s when the whiteboard pens make their appearance. Where do you start though? How much detail should you include? Technology decisions included or omitted? UML or block diagrams? Join us as we look at some typical diagramming bloopers and show you how to produce effective sketches.

 

If you want to get a feel for what I'll be talking about in these sessions; take a look at Deliberate practice, effective sketches, Start with the big picture and C4: context, containers, components and classes.

I'm pleased to say that I'll be speaking at the GOTO conference in Aarhus in a couple of months. GOTO Copenhagen in May was a blast so I have high expectations for Aarhus where I'll be presenting a session on the So you think you're an architect track called The Frustrated Architect...

The IT industry is either taking giant leaps ahead or it's in deep turmoil. On the one hand we're pushing forward, reinventing the way that we build software and striving for craftsmanship at every turn. On the other though, we're continually forgetting the good of the past and software teams are still screwing up on an alarmingly regular basis.

Software architecture plays a pivotal role in the delivery of successful software yet it's frustratingly neglected by many teams. Whether performed by one person or shared amongst the team, the architecture role exists on even the most agile of teams yet the balance of up front and evolutionary thinking often reflects aspiration rather than reality.

If we really do want to succeed, we need to get over our fascination with shiny new things and starting asking some questions. Does agile need architecture or does architecture actually need agile? Have we forgotten more about good software design than we've learnt in recent years? Is emergent design really just about foolishly hoping for the best? Does any of this matter if we're not fostering the software architects of tomorrow? How do we move from frustration to serenity?

As the abstract says, software architecture is a crucial element for most software development projects yet it's frustratingly neglected. Come and join me for a look at the state of software architecture past, present and future.

Last month I delivered a presentation to the local British Computer Society entitled "IT projects; if you can't beat them, change the game". Much of what I talk about usually relates to the internal quality of software systems and specifically it's aimed at software architects and developers. This presentation was a bit of a change for me in that it focussed on the people that pay for our services such as customers, business sponsors and so on.

Why? Quite simply; I'm fed up with seeing IT suppliers ripping off customers with late or failed deliveries that are over budget and low on quality. There's a great article called IT industry 'oligarchy' is 'ripping government off', MPs told that talks about this from a UK government perspective, but it isn't limited to the public sector by any means. While most IT suppliers say that they run their projects in a structured way (e.g. with PRINCE2) using the latest technologies and development practices, in reality project management is ad hoc at best and the deliverable barely reaches the lofty heights of the minimum viable product. Things like documentation and configuration management? Well apparently they've gone out of fashion, never to be seen again. Oh, and they use continuous integration and automated unit testing? Congratulations and so they should ... welcome to the 21st century!

Like yin and yang, the presentation was a story of two halves that together aimed to bring balance to the force. I opened up "traditional" software projects, threw out what many customers consider to be "normal" and then showed how collaborative, iterative and agile ways of working can solve many of the major problems associated with IT projects today. If you're interested, you can view the slides online or download them as a PDF file.

Whether you agree with everything in the slides or not, the key message is very clear ... IT projects don't have to be like this and *you* have the power to change the game.

I've written about this before (Everybody is an architect, except when they're not), but let me start by saying it again - there is no conflict between agile and architecture. Even the most agile of projects will have architectural concerns of some description and these things need to be thought about up front. Agile projects therefore need architecture.

Where is the conflict then? Well, the conflict is between the desired outputs of agile versus those of big up front design. One of the key goals of agile methods is to deliver customer value, frequently and in small chunks. It's about moving fast and embracing change. The goal of big design up front is to settle on an understanding of everything that needs to be delivered before putting a blueprint in place.

Separating architecture from big up front design

"Architecture" is about the stuff that's hard or costly to change. It's about the big or "significant" decisions. It's the sort of stuff that you can't easily refactor in an afternoon. For example, this includes core technology choices, the overall high-level structure (the big picture) and an understanding of how you're going to solve the complex/risky/significant problems. Big up front design typically covers these architectural aspects but it also tends to go much further, often unnecessarily so. The key to just enough up front design is to differentiate what's important from what's not. Defining a high-level structure to put a vision in place is important. Drawing countless numbers of detailed class diagrams before writing the code most likely isn't. Understanding how you're going to solve a tricky performance requirement is important, understanding the length of every database column most likely isn't.

The waters are muddied in the real world

There's a part 2 to this blog entry but before that I want to try something. The problem with the real world is that it's less than ideal, particularly with respect to software projects. Unless you're incredibly lucky, there will always be real world constraints that prevent you from taking a text-book approach to solving problems. In his QCon London 2011 presentation entitled Why Don’t We Learn!?, Russ Miles explains that this doesn't really matter. And I agree - you just have to find something that works for *you* rather than jumping headfirst into "the next big thing" because "it worked over there for them".

So here's my challenge to you. Let's imagine that you've been asked to lead a software project to replace an ageing Internet Banking system. The key facts are presented in the image below. To constraint it further, let's say that rebranding the existing system is out of the question and you've been committed to a delivery at the 4 months point. After all, things like this do happen in the real world.

This is a fictional situation but it highlights some of the real world challenges that many software projects face. How would you approach this project? What would you deliver? Feel free to leave a comment or copy the image if you want to post something longer on your own blog.

I'm pleased to announce that two of our popular training courses are being run in Jersey at the end of June.

1. Software Architecture for Developers

Designing software given a vague set of requirements and a blank sheet of paper is a good skill to have, although not many people get to do this on a daily basis. Software Architecture for Developers is a two-day training course about "just enough" software architecture, designing software and leading a software project from a technical perspective. If you're leading software projects now, want to lead teams in the future or are involved in the initial design and estimation process for new projects; join us and enjoy a mix of listening, discussing and practicing software architecture. This course is applicable whether you're building applications in .NET, SharePoint, CRM, Java, PHP, Ruby, etc.

• Dates: Tuesday 28th June 2011 and Wednesday 29th June 2011 (2 days)
• Cost: £895 per person (a £100 discount is available to Jersey/Guernsey based BCS members - proof of membership required)
• Trainer: Simon Brown
• Laptop required: No, exercises are paper-based
• More details can be found at www.softwarearchitecturefordevelopers.com
• To book, please e-mail Simon Brown (simon.brown at codingthearchitecture.com)

2. Load Testing for Developers

Load Testing for Developers is a one-day training course to get you started load testing your web applications. 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. Load testing is a natural extension to the software architecture, technical lead and software developer roles. This course is applicable whether you're building applications in .NET, SharePoint, CRM, Java, PHP, Ruby, etc.

• Date: Thursday 30th June 2011 (1 day)
• Cost: £495 per person (a £100 discount is available to Jersey/Guernsey based BCS members - proof of membership required)
• Trainer: Simon Brown
• Laptop required: Yes, you will need to bring your own laptop as this is a very practical course
• More details can be found at www.loadtestingfordevelopers.com
• To book, please e-mail Simon Brown (simon.brown at codingthearchitecture.com)

Having been involved in several upgrade projects over the last few years, one thing I've often noticed is the poor quality of data that can be present in a large and long running system. This can present problems for upgrading and usually means that you have to spend quite some time fixing the data first.

Upgrading is difficult and causes regression tests to fail as:

The new system may have more data checking and refuse the old data.

The new system may be more precise e.g. not rounding a number, taking a sign into account etc.

The new system may be using data that was not used before e.g. data entry staff not bothering to enter a product's weight into a form as 'it is never used'.

Years of copy and paste can leave a vast amount of junk that fail consistency checks.

After you have corrected the data for upgrade, the original system has much higher quality data and other issues and inconsistencies have been solved. In a recent system we also saw large performance improvements due to duplicate and junk data being removed. On another system we saved the operations staff may hours work a week as the data improvements meant a large number of post report corrections were no longer needed.

So why isn't this analysis done on a regular basis to help keep a system healthy? The main reason is simply that it's just too hard for the operations staff to do. Therefore when you're designing a system you should take this into account and enable these kinds of maintenance tasks. This involves reporting and having tools that can correct sets of problematic data.

Some things to consider:

How easy is it to identity and delete orphaned data i.e. If you can't get to some data is it required?

Can a user identity data that has not been used for a long time? Can they then archive it?

Can you identify identical or similar data? A common example is user information that differs only by capitalisation e.g. an address.

Can the user run arbitrary consistency checks that go beyond the database rules? E.g. I've recently written a tool to allow an operations manager to run xpaths over data to check for bad bookings.

Can the user bulk load sets of missing or corrected data?

Please don't rely on database tools to do this as your operational staff probably won't know how to use them and your DBAs don't understand the business domain to analyse the data. You need tools at the appropriate level for the appropriate people and consider the complete lifecycle of your product.

Add a comment

Posted by Robert Annett on 15 April 2011 15:29:43 BST #