Coding the Architecture - frameworks tag

There's nothing new under the Sun...

Wed, 17 Dec 2008 21:57:27 GMT

Ah, writing frameworks - the most noble of pastimes for experienced developers!

I've written my fair share of frameworks over the course of my career in software development: workflow, integration, content management, validation, data-binding, remoting. And with the wisdom of hindsight I think I regret having visited each of them upon the rest of the development team!

These frameworks all served a purpose (apart from scratching my framework-writing itch). They bridged a gap between the technologies we were using and the requirements being implemented, thereby making these implementation tasks easier.

However, these requirements weren't particularly unusual and the technologies chosen certainly weren't. So it seems unlikely that these frameworks were fulfilling some new purpose that couldn't be met by an existing piece of software.

These days if I find myself writing a framework I appreciate a bit of introspection or criticism to keep me honest.

Why aren't you using an existing framework?

Many home-grown frameworks (my own included) are backed up by some strong criticism of the alternatives. Much of this comes from ignorance of those alternatives or a belief that yours won't exhibit the same, or indeed any, deficiencies.

As a general rule I'd say that you really don't want to own your own framework code. At the very least you can opt to defer taking ownership by selecting an open source alternative or using professional services support for a commercial offering. This makes speculative concerns about third-party frameworks less, well, concerning.

I'm surprised how many development teams rely on open source software yet prefer to hack their way around problems (with vitriolic commentary) rather than contribute a defect report, let alone a fix! It's not just polite, it's less likely to result in regression defects.

What opportunities does rolling your own offer?

If you are writing your own framework then it pays to be clear where it's going to recoup the cost of ownership. Creating a generic solution is unlikely to be the most efficient way of meeting your requirements and moves the framework from the problem domain into the abstract, making it less intuitive to those most likely to be working with it.

Keep things no less specific than necessary, targetting your problem domain, environments and development process. Abstract where it provides clarity rather than as a precursor to world domination.

Is it too late to change your mind?

Although our architectural decisions are supposed to be costly to change, successful designs often reduce that cost, making other choices less important.

Rolling your own framework is not an ideal design decision and is simply incumbent due to a lack of suitable alternatives. The veracity of this statement should be checked from time to time as it will give you the chance to draught someone else's development effort.

It's not necessarily safe to assume that over time your framework will become better. It will probably become bigger, but since it's likely of lower quality than a third-party alternative its benefits may become outweighed by its ongoing maintenance and training costs. Improvements in the "competition" will also mean you may have to run just to stand still.

If you are intent on rolling your own framework then don't manufacture differences just to set your solution apart: they'll simply make it harder to migrate to other frameworks should the need arise.

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.