Coding the Architecture - quality tag

Becoming more architecturally aware - part 2

Tue, 28 Oct 2008 20:18:49 GMT

Last time I talked about how we need to understand how application frameworks are designed and work behind the scenes in order to produce code that is consistent and compliant with the overall architectural principles. The second aspect that we need to become architecturally aware about is the underlying technology.

Again, let's put this in context of my current .NET project. I have much more Java experience than .NET experience; I've written some C# and I've played with Silverlight, but ASP.NET is new to me. Thankfully, the concepts behind ASP.NET translate fairly directly with those behind JSP, so it's not as if I'm tackling this from a standing start. Having said that, I've felt that it's really important to get to grips with the underlying architecture of the technology so I can be sure that the code I write, again, integrates properly into the overall architecture. An example here would be the ASP.NET page life cycle. Like JSP, ASP.NET pages have a series of things that happen to them when a request is made, which includes creation of the request/response objects, page compilation, page instantiation, calling page event handlers and so on.

Knowing the finer details of a programming language is one thing, although using or not using new language features such as generics isn't necessarily going to negatively affect the architectural integrity of the solution. Not understanding something like the page life cycle of ASP.NET could. For example, it's important to understand the page life cycle so that you understand when objects can be shared/cached. Session management is another important thing to understand, and blindly throwing objects into the user's session can have architectural implications if your application needs to scale horizontally and you need to implement transparent session failover using session replication.

Being more architecturally aware doesn't necessarily mean that you need to understand the entirety of the bigger picture, but you should understand how to write code that is architecturally compliant. And that means understanding more about how the underlying technologies work.

Becoming more architecturally aware - part 1

Fri, 17 Oct 2008 09:06:00 GMT

In my Mind the gap essay and Why Software Projects Fail presentation, I talk about how we as developers should be more architecturally aware if we are to bridge the gap between the code and the overall design. I include myself in this statement because recently I've started adding functionality to an existing ASP.NET website and I've found it essential that I become as architecturally aware as possible in a short amount of time. Let me provide a couple of real world examples.

Although I'm adding behaviour that is in effect isolated from the rest of the application, my code is still a constituent part of the overall architecture. In addition, I'm using some of the utilities and frameworks that the development team have already produced. Clearly I need to understand the usage patterns in order that I can be productive as a developer on the team but, furthermore, I need to understand something about the inner workings in order that the code I write is architecturally compliant with the rest of the system. I'm sure you've seen this yourself, but give a few people the same framework and you'll see usage patterns that you hadn't even dreamed of. Some will be what you expected, some may be better than what you expected and some may break your framework in horrible ways.

If somebody on the team is taking responsibility for the architecture and undertaking reviews, it's possible to catch those instances where application framework code isn't being used as anticipated. Sometimes, it's even possible to automate these architectural conflicts with a set of automated unit tests. If, however, nobody is taking on this architectural guardian role and everybody is simply using what they've been provided with, then this is where problems start to creep in. Sometimes they creep in from people adopting a copy-paste approach to development (i.e. copying another class because it "works") and sometimes they creep in because people just aren't aware of the hidden side effects of their framework usage pattern. Either way, problems introduced because of a lack of architectural awareness might not show up during local single-user testing, but could prove critical when the system is rolled out to a wider user base.

The only way to get really productive with existing application code is to dive into it and understand how it works at both a conceptual and implementation level. Only then can you ensure that the code being written is compliant with the rest of the architecture, which is crucial for the quality and integrity of the solution. This is one way in which developers should become more architecturally aware and next time I'll discuss another.

How good is good enough?

Fri, 14 Mar 2008 11:11:38 GMT

I've undertaken a couple of project reviews recently where I've been asked to assess whether the code is "good enough". All software systems have a real-world context and the project has to balance scope, budget and schedule. With this mind, what is "good enough"? Kevin has touched upon this before and I've talked about having just enough quality, but what does having "good enough" code actually mean?

Here are some of the questions that I try to answer.

Is there a comprehensive set of automated unit tests, or evidence that the code has been unit tested (e.g. presence of boundary/null checks in the code)?
Have good object oriented principles been adopted when putting together the design? For example, do classes have clear responsibilities?
Have standard APIs and technologies been used? In other words, have any wheels been reinvented? If they have, is the alternative solution as good or better than the standard solution in this context?
Does the codebase feel consistent, in terms of style and the approach to solving problems?

The last point raises some interesting questions. It's really easy to get carried away when doing code reviews and flag up a large number of points ranging from inconsistent code formatting and lack of comments through to using better APIs and the latest language features to solve problems. Given the real-world context in which the system exists, that piece of software needs to solve a business problem and points like these are fairly minor in nature¹. However, an inconsistent codebase can highlight those instances where there is an overall lack of explicit technical leadership.

If you were to look at your own system, how would you decide whether the code was good enough?

¹ Although it's arguable that points like these are minor in nature, I still think that it's important to ensure they are raised. Personally, I don't like to see things like this in the codebase for a system that I'm responsible for, but you need to present findings from activities like code reviews as appropriate. These minor points are important for the development team, but not so important if the key project stakeholder is asking you whether the code is good enough.

Poor execution

Mon, 30 Jul 2007 18:23:00 GMT

Let me paraphrase an interesting statement I heard last week about a software system.

The high-level design is fine, but the execution was poor.

I found this interesting and started thinking about it from several perspectives.

You can define the best architecture in the world, but you still need to successfully deliver on that architecture.
To ensure a successful delivery, you can't simply hand-off the architecture.
I'm a strong believer that, particularly on smaller projects, the architect should take responsibility for the technical quality of the solution.

Software architects are the people responsible for ensuring the technical quality of the solution and, by this, I'm referring to quality at the macro level (e.g. meeting the non-functional requirements) as well as at micro level (e.g. coding standards, unit test coverage, use of continuous integration). More often than not, I find that teams let the latter fall down the gaps between the architect(s), developers, build manager, configuration manager, etc. In the event that nobody has been granted explicit ownership, I'd say that this is another aspect that falls squarely underneath role of the software architect.

Quality

Tue, 02 May 2006 21:01:41 GMT

Kevin posted a great entry about his first architect experiences and it's inspired me to write a follow up about quality.

Contrary to my expectations, I've found that being separated from the development team has made me more tolerant of their mistakes, despite being less able to address these mistakes directly. This I attribute, in part, to being better able to see the value of less costly development. Of course, this is not to say that code quality, mentoring and review aren't still very important! However, I find that I'm less exacting and more pragmatic - if I were to press for the quality that I'd deliver myself (as a lead developer) then I'd be negating some of the cost benefits of having got someone else to do it in the first place! As a lead developer I knew when things weren't up to scratch and I'd do something about it; as an architect I have the context and obligation to determine when things are "good enough" and be confident not doing anything about it. Sure, it's frustrating not being able to roll your sleeves up and show everybody how it should be done ;) but there's also satisfaction to be taken from making a call on whether something's fit for purpose.

This is something that I can certainly relate to and I also feel the same frustration at times. So, let's explore the quality aspect further. Imagine a scale that measures quality. What Kevin is saying is that, as a lead developer, you always strive for the ideal level of quality. Call it perfection if you wish.

Take a step into the architect's shoes and you have to think about the cumulative/average quality across the whole development team. Clearly, asking everybody to achieve perfection isn't realistic, so it's your job as an architect to ensure that quality across the board is adequate. Perhaps that's the wrong word, but let's say the quality has to be as good as you can get it within the given time and budgetary constraints.

Getting the quality towards the top end of that scale would be my own goal, but how far would you try to push it? How much is "just enough"? If you insist on nothing less than perfection, how do you get your team to achieve it?

Reviews

Fri, 17 Mar 2006 15:05:20 GMT

I recently read chapter 5 of Applied Software Project Management and it was all about reviews. Inspections, desk checks, walkthroughs and code reviews were all mentioned along with the compelling argument that reviews have a very high return on investment because catching a defect early is much much cheaper than catching it later. Think about it, a couple of hours spent reviewing your key use cases is much cheaper than getting somebody to rewrite and retest a software component that works but does the wrong thing.

I'll be honest, I'm as guilty as the next person in not doing enough reviews, but why do we let this happen and how can we readdress the balance? The first part of the question is easy to answer and I'd like to offer up the following suggestions.

Time : there are always better things to be doing.
Context switching : it takes a while to switch from what you're doing and focus on something else that you might not necessarily be familiar with.
Learning curve : As an architect, you're not going to know the entire system inside-out, so there's the learning curve to consider when you review something you've not seen before.
Tools : if you've installed code checking tools (e.g. PMD, Checkstyle, etc) then there's a tendency to "leave it to the tools".

So, how do we address this? Well, for code reviews, an easy answer is to adopt extreme programming's pair programming, but of course this isn't always possible and/or desirable. Something that I recommend other architects do is delegate some of the reviewing to others on the team, perhaps sitting with them for the first few reviews to help them see what you want. This is good because not only does it free you up a little, but it helps develop their skillset and spreads knowledge of the project across more of the team.

Ultimately though, you just need to make time for reviews. Ensure that they are included in any estimates and, if you're an architect, ensure that you set some time aside for reviews. As an architect you're probably responsible for the technical quality and you can't assure it if you don't review it.