Getting up to speed on modern architecture

Question

I don't have any formal qualifications in computer science, rather I taught myself classic ASP back in the days of the dotcom boom and managed to get myself a job and my career developed from there. I was a confident and, I think, pretty good programmer in ASP 3 but as others have observed one of the problems with classic ASP was that it did a very good job of hiding the nitty-gritty of http so you could become quite competent as a programmer on the basis of relatively poor understanding of the technology you were working with.

When I changed on to .NET at first I treated it like classic ASP, developing stand-alone applications as individual websites simply because I didn't know any better at the time. I moved jobs at this point and spent the next several years working on a single site whose architecture relied heavily on custom objects: in other words I gained a lot of experience working with .NET as a middle-tier development tool using a quite old-fashioned approach to OO design along the lines of the classic "car" class example that's so often used to teach OO. Breaking down programs into blocks of functionality and basing your classes and methods around that. Although we worked under an Agile approach to manage the work the whole setup was classic client/server stuff. That suited me and I gradually got to grips with .NET and started using it far more in the manner that it should be, and I began to see the power inherent in the technology and precisely why it was so much better than good old ASP 3.

In my latest job I have found myself suddenly dropped in at the deep end with two quite young, skilled and very cutting-edge programmers. They've built a site architecture which is modelling along a lot of stuff which is new to me and which, in truth I'm having a lot of trouble understanding. The application is built on a cloud computing model with multi-tenancy and the architecture is all loosely coupled using a lot of interfaces, factories and the like. They use nHibernate a lot too. Shortly after I joined, both these guys left and I'm now supposedly the senior developer on a system whose technology and architecture I don't really understand and I have no-one to ask questions of.

Except you, the internet.

Frankly I feel like I've been pitched in at the deep end and I'm sinking. I'm not sure if this is because I lack the educational background to understand this stuff, if I'm simply not mathematically minded enough for modern computing (my maths was never great - my approach to design is often to simply debug until it works, then refactor until it looks neat), or whether I've simply been presented with too much of too radical a nature at once. But the only way to find out which it is is to try and learn it.

So can anyone suggest some good places to start? Good books, tutorials or blogs? I've found a lot of internet material simply presupposes a level of understanding that I just don't have.

Your advice is much appreciated. Help a middle-aged, stuck in the mud developer get enthusastic again!

Please!

Answer 1

Sitting on the Beach - Preparation

Make a list of everything you don't understand. At the final stage, this list shall be your checklist. Clear your mind – get yourself to a fresh start, "forget" all the confusing details you already know about your architecture. Dig up every document created by the original architects. Get the documentations for every technology used in your project. Make coffee.

Floating - Managing Complexity

To float, you need to manage complexity. If you don't deal with complexity properly, you'll dive into details when there's absolutely no need, and you won't know how and where to stop, sinking right into the bottom and drowning.

"My approach to design is often to simply debug until it works, then refactor until it looks neat"

I think I used to be just like you. I developed solutions by starting from scratch and adding one piece at a time, eventually containing a complex structure inside my head. I didn't plan the architecture, I didn't separate design and implementation, I just coded, debugged, refactored. It worked: since complexity grew slowly, I had no trouble understanding the architecture that emerged.

This approach simply isn't good enough when "inheriting" a complex architecture planned by others; you cannot swallow the entire structure at once - because there are too many details, and you cannot randomly swallow little bits - because you won't understand how they all relate to each other and you'll never get to see the big picture.

Software is a puzzle of complexity management. There are very big pieces, sometimes referred to as "subsystems", which compose the big picture. Each of these is composed of smaller pieces, which in turn are also composed of smaller pieces. When you look at the code, all you see is the tiniest pieces. So forget about the code itself for now, at least until you see all the bigger pieces.

Swimming – Mapping the Architecture

The first step towards floating is seeing the big pieces. To do that, you need maps. The map to the biggest pieces is the highest-level architecture. If the original architects left you with no such map, you'll have to create it by yourself. Just like it is impossible to map a region from inside a valley, you cannot map your architecture from low-level details. You need to stand at the top of a mountain to get a 360-degrees-view of all the valleys, hills and paths. You need to map your architecture from the top.

After you have this top-level map, you should get maps for the parts composing it - just like you create an un-detailed map of an entire region, and then create separate detailed maps of sub-regions. A map should describe the different subsystems. At the very least, it should describe the responsibilities of each subsystem, its external interface, and how it interacts with other subsystems.

Diving – Managing the Details

There is this principle in diving which says you shouldn't move between depths too fast, because of the changes in pressure. This principle holds. When you move from dealing with one subsystem into dealing with one of its internal subsystems, make sure you only dive into the next level of complexity/abstraction. Let your mind handle one tier at a time.

Separate concepts, patterns, interfaces and implementations. nHibernate is an Object-Relational Mapping (ORM) solution. Thus, before you deal with the details of nHibernate itself, you need to make sure you understand the general concept of ORMs and their place in the world. Factory is a design-pattern, so before you deal with Factory you should understand what design-patterns are and what their role is.

Technologies raise and fall, but concepts remain. Once you get the concepts, it really doesn't matter much – on an architectural level – how these concepts are manifested.

The fact that your architecture is loosely-coupled is actually a good thing, because it means you can understand the role of one subsystem without the need to know much about other subsystems. The fact your architecture makes use of interfaces is also good – it means you can learn how elements interact with each other without learning how they work internally.

Waterskiing – Acquiring Distilled Knowledge

There is one book that I think is a "must-read": Code Complete by Steve McConnell. It changed my professional life.

---

I hope that this post managed to help you in some way and isn't a complete waste of your time.

Answer 2

Here are some suggestions, by no means a complete how-to or all-in-one answer;

• Make time in your working day to learn about the new stuff. Make this time in your working day because it is part of your work. It's not something you should do only in your evenings or at weekends. If you want to spend some of your own time learning it, go right ahead, but don't fail to recognise that learning is part of your job and don't get into the mindset that you have to hide your ignorance at home or that not knowing everything is fatal to your career. It's up to you to balance learning time and working time.

• Get some large sheets of paper and a box of coloured pencils (or MS Visio if you prefer). Start drawing two types of diagrams:

  • Mind maps, to diagram your understanding of the new technologies. If you don't know what mind maps are, hit Wikipedia to start with.
  • Architectural diagrams of the system you are responsible for. Whether you use UML or another widely-used format or one of your own devising is up to you.