Agile teams are neglecting design.
I can already hear your objections. Surely, you will say, many Agile teams these days do test-driven development and TDD is all about design. I absolutely agree, after all, I dare not question Uncle Bob who, in his “Agile Principles, Patterns, and Practices in C#” book clearly says
“The act of writing a unit test is more an act of design than of verification”.
The problem, however, is not if we are doing TDD but how we are doing it. Writing unit tests before production code, watching the tests fail, writing corresponding production code until the test passes and then refactoring requires discipline. Many new Agile teams lack that discipline. To gain the full benefits of TDD also requires a lot of practice and teams may simply have not had the time to accrue enough.
These two obstacles aside, I still don’t see the practice of TDD shaping the design of teams’ code in a way that Steve and Nat describe in their excellent “Growing Object-Oriented Software, Guided by Tests” book. I think among the reasons sits this one: frameworks.
I see this time and time again: a new engaged, eager and energised Agile team sits together to start a new project. They want to break away from the old ways of working. They have already been freed from the heavyweight processes which required lengthy documents, endless approvals and then subjected them to a stream of bugs arriving weeks or months after they last touched the affected code. They also take this as an opportunity to break away from the technical baggage accumulated over the years. Not doing so would be to neglect the Conway’s law.
And then what does a team do? They pick a framework. Chances are, if you are an Agile team writing a website in .Net you will go for the ASP.NET MVC framework. If you are trying to move away from the monstrosities of Java Enterprise frameworks or got tired of Spring you might be moving to grails. If you are more daring you drop you old technology altogether and pick rails. Add an ORM on top or something from the NoSQL pallet and your fresh new architecture is ready waiting for you.
While there is absolutely nothing wrong with these frameworks and technologies, making such choice means you have given up design decisions that you would have otherwise had to think about. You start working within a framework and then your thinking re-focuses to consider how best to fit your problem into the skeleton which is already in place. It might be slightly awkward to write some of the unit tests but you just blame that on your inexperience with the new technique.
Isn’t it ironic, that as we free ourselves from the rigidity of the organisational processes we are willing to subject ourselves to the rigidity of the framework structures.
In the short time, we go astonishingly quickly, new functionality flows into releases, new pages appear, database expands magically and there is none of that old hand-crafted SQL to worry about. Many Agile teams are probably still at this stage. The will go on to neglect design, they won’t question the structure of their code at various levels, they won’t reevaluate their architecture. Then strangely, release by release, they start to slow down. Features become more difficult to implement, changes solidify, codebase stagnates.
I just hope it’s not your team.
Which one do you prefer, Pepsi or Coca-Cola? According to the market share the split is somewhere around the middle. However, as Malcolm Gladwell mentions in “Blink“, in a random sip test, where people are asked to compare the two beverages based on a single sip, Pepsi is an outright winner. The reason is simple, we are not too good judging complex favours quickly but we can easily detect sweetness and Pepsi has more sugar. Similarly, following one of Joel’s favourite examples, most electrical retailers set their TV sets on display to the maximum brightness as we tend to judge the picture, at first glance, mainly by brightness.
It seems to me, usability and graphic design follow similar pattern when it comes to web sites. We can’t quickly and easily evaluate usability but we are very quick to notice and judge the appearance. Therefore, when developing new websites, teams often focus on the graphical design, adding many shiny or elegant gadgets, rather than spending more time on improving the usability.
After all, in the quick and often rehearsed demos, it is the functionality and appearance that will get noticed by the stakeholders. It’s the prominent design that will attract CEO’s attention, it is the choice of colours that might spark a discussion.
In many cases however the ease of use and friendliness of your site is what will attract and, more importantly, keep your users loyal. It’s what will have the greatest impact on those, who will have to use your system every day. You may choose to impress them on the day of the release but then fail to keep them happy in the long run.
So don’t just bloat your application with sugar, providing poor user experience under a shiny veneer leaving the users with a nasty after-taste. Delight your customers with applications so easy to use that they will be happy to keep coming back.
The other day I was looking at one web application, probably like many similar across organisations, where a team of architects ensure the enterprise standards of application design are observed.
I needed to add a new menu item so I started with the UI layer to see where the menu is displayed. Well, that wasn’t as easy as I expected but I finally found the bit of code. No surprises here, it gets some data from the business layer and dumps it on the screen. I was expecting slightly more HTML in the code, I’ll find it in the layer below I though.
So I dig deeper.
It turned out data for the menu does come from a business layer but it’s called via a web service and so it actually took another layer of transforming objects into XML back into objects before I traced where the data is assembled.
Another surprise, the business layer code barely mentions I’m dealing with a menu, there are no menu-specific domain objects or HTML markup I though got buried here. Instead there are some generic data object and a reference to the data access layer.
So I dig deeper.
Welcome to level 4, the Data Access Layer, otherwise known as DAL. Here, I would be expecting simple calls passed through to the database of some sorts. Will I be surprised by an unexpected addition of some HTML adornments? No. Instead there is a lot of logic dealing with user security, access levels, calls to some spurious stored procedures and… yes, you’re right a call to the SQL Stored Procedure returning the menu structure. I’m still not sure how it needs quite so many parameters.
So I dig deeper.
At last, the final level in the hierarchy, I hit the rock hard bottom and in front of my very eyes a monstrosity of a Stored Procedure unveils. It’s a few hundred lines long, it makes calls to several other stored procedures, the missing HTML is lurking around here all-right and some data got hard-coded as it clearly didn’t fir the table design.
I wonder, is this the structure that the enterprise architects envisaged? Was it an evil DBA insisting to control all the data? Was it a developer more at home with T-sql than .Net?
I don’t know. What I do know, is that it’s not an N-tier architecture. It’s five levels of obfuscation that could easily put off anyone trying to make any sense of the design.