Scalability Drives the Architecture | Extreme Programming Refactored: The Case Against XP

Changing a nonfunctional requirement can result in a complete rethink of the system architecture. The effect is on a different scale from functional requirements, which also affect the architecture but to a lesser degree. Unfortunately, XP makes very little distinction between the two: Everything s fair game, open to change (no, make that embracing change. Changing requirements during coding is invited in XP). It doesn t seem to matter that for nonfunctional requirements, the rules are very different.

The XP approach to design is as follows : Design what you need for the current-2-week iteration (test first) and code it. Design what you need for the next 2-week iteration, and code it, and so on. Incremental development includes incremental design.

Thus, if the current iteration will just be used by, say, five concurrent users, then the architecture should be targeted at five concurrent users ”even if the team knows that the system is intended to be used for five thousand users in a later iteration.

The architecture for a 5-user system would be completely different from the architecture for a 5,000- user system. The choice of platform, programming language, hardware, tools, and frameworks might be different. Nonfunctional requirements ”and scalability, in particular ”have a huge effect on the system architecture.

Nonfunctional requirements are an extreme example of the shortsightedness of YAGNI ”just designing for the current iteration. Let s take an example from Extreme Programming Installed , just to prove we re not making this up.

Example from Extreme Programming Installed: Patient Records Database

Back in Chapter 12, we gave a critique of Chapter 26 from Extreme Programming Installed (hereafter known as XPI26 ).

The example of emergent design provided in XPI26 is an application that, through user stories, the developers have identified needs to store patient details for up to 10 million patients. It stands to reason that we would need to use a database for such a system. However, XPI26 suggests instead that you should initially (for the first few iterations, at least) target the system at a smaller number of patients (say, 1,000 or 10,000), and just use files for data persistence.

The purported benefit is that this should be easier, because writing to files is simpler than writing to a database, and that this gives the patient record structure time to stabilize. Fields can be added and removed more easily: Just write little programs to do it. Then, when you re ready to add patient number 10,001 to the system, it should be really easy to migrate your file-based , proprietary storage system to a real database, because you also followed the once and only once rule (you did remember to follow that rule, didn t you?).

The implication in XPI26 is that if your code is well factored (so that there is no duplication of code ”that is, each piece of functionality is written once and only once ), then migrating the design from a 10-user system to a 10-million-user system would be as easy as changing the code in two places (one for reading the data, the other for writing). Of course, this is entirely fallacious, because it oversimplifies the issues involved in extending an architecture to make it scalable. Failover, transaction support, server clustering, and so on also play a part. In many such cases, the entire architecture can change dramatically, not just the little hole that the data gets squirted through.

Even if (for the sake of argument) changing the data access layer were the only issue, we would feel much more comfortable making changes in a database schema and letting a real database like Oracle or MySQL handle the adding or removing of columns , relationships, and constraints for us, while maintaining integrity of the existing data. Database engines are designed specifically for that sort of thing, after all. Why spend time writing your own file-based persistence mechanism (however simple) when you know that soon you will need to replace it with code that accesses a real database? More to the point, why do this when it in fact works out simpler to use the more complex database?

In this case, as in many others, the apparent simplicity of taking a roll your own approach turns out to be illusory. The effectiveness of a design isn t just about how simple it is to implement at the time, it s also about how easy it is to transition between different versions ”something that, ironically, can be better achieved by spending more time documenting the design, thinking it through, and letting the emergent design take place in the class model ”before spending time writing the production code.

It s true that databases are more complex than files; however, the database system has already been written for us. It s there, it exists. Pretending it doesn t exist doesn t make our job any easier. In fact, the proprietary file storage solution that Jeffries recommends can only result in a lot more coding, because there are issues such as concurrency, file locking, transactions, data integrity, data marshalling, constraints, and so forth that we would have to write ourselves for a multiuser system. This wouldn t be apparent at first; files would at first seem like the simplest way forward, assuming that the way forward is only for the next couple of weeks. However, gradually all of this extra code would need to be written as these problems pop up (most likely reported by users who are being forced to use our half-baked database system) until we suddenly find that we ve written our own in-house version of SQL Server. If we chose instead to write to the more complex database first, all of this would have been taken care of for us.

Usually, the simpler option is the preferable one. It s possible to learn a lot from this area of XP s teachings ”particularly simplicity, once and only once, and simply how to refactor existing code. However, it s also important to take these teachings with a pinch of salt and not to get too carried away with them. If XP was simply saying, Here s a nice, safe way to improve existing code, then we wouldn t have a problem with it. Instead, the overall process prescribed by XP leads to a design process that can fool the customer (and the programmers) into thinking the project is nearly complete when success is really a long way off.

The patient records example in XPI26 demonstrates that XP takes a throwaway approach; that is, XP encourages us to write code that we know is going to be thrown away later, as if it s free. In this example, Jeffries deliberately ignores the scaling issue. If the code were written to a database first, then it wouldn t have to be thrown away.

In the same way that C3 generated a quick illusion of success, emergent design generates a quick illusion of progress. The basic product is complete ”all that s left is to write in the complex logic that takes care of alternative scenarios (such as when the user decides to click some buttons in a different order than the one that the programmers anticipated, or when two users try to access the same record simultaneously ). We would say we re about 90% complete. . . . ^{[15 ]}

This can lead to premature boasts of success. In 4 years time I have won the Nobel Peace Prize. Can I have that book deal now?

Throwing Away Code

As we ve explored elsewhere in this book, throwing away code is a central theme of XP. Yet to evolve designs by repeatedly throwing away code ignores the fact that late projects get late a day at a time, then a week at a time, then a month at a time. Pretty soon they re 4 years late if they haven t been inexplicably cancelled by then.

We d like to introduce a radical concept, though. What if we could throw away bad code before it ever got written? What if we didn t have to write unit tests for throwaway code? What if we could actually visualize a design before coding?

For more about this radical new concept, see the section The Cost of Change Curve (aka the Cost to Fix Defects Curve) in Chapter 13.

We Can Toss It Out

(Sing to the tune of We Can Work It Out by The Beatles)

If we code it your way
There s a chance the code will fall apart before too long
So let s code it my way
Then we can refactor it until the day is done
Then we can toss it out We can toss it out

Days are very short, they end at fiiiive
So you ll have to toss that, my friend
I have always thought BDUF s a criiiime
Instead we ll refactor till the end

SATIRE WARNING
The Piggy Scale of Process Robustness

Or, Striking the Balance: Finding the Sweet Spot Between Speed and Agility and Process and Safety

The Three Little Pigs were very excited, because today they were going to leave the safety of their uncle s home and find a place to live. In an early-morning stand-up meeting, they linked their little trotters together and collectively decided that they would each head off in a different but roughly similar direction and find a nice place to build his house. They briefly discussed the architecture ”four walls, windows , that sort of thing ”but were too excited to discuss the details any further. They just wanted to get building and move in as soon as possible.

The first little pig found a lovely spot in a delightful rural location on the top of a hill, with charming views and excellent potential for the budding DIYer. So he set to work, resolving to evolve the design of the house as he went along. With this in mind, he decided to build his new home out of the most agile material he could find, which just happened to be straw. After all, it never rained in these parts , and he knew that he would be able to build something really quickly out of straw ”not to mention that he would be able to embrace change and refactor the design very easily.

Unfortunately, the reality turned out to be quite different from the theory, and the straw kept falling down every time a breeze blew up. The fact that he was on top of an exposed hill, with 20-mile-per- hour winds whipping around his chubby legs, did not help his progress or his mood. Soon he was thoroughly frustrated, and his little trotters had turned blue from the windchill .

Almost 4 years later, he was still busy embracing change and clutching at straws flying around in the breeze, but after only one-third of his straw house was built, he gave up, wrote a book about his success, and used the proceeds to buy himself a Winnebago.

On the morning that the second little pig began building, he found a nice picturesque glade in the middle of a forest, with excellent local amenities (it was near a babbling brook). He had decided enthusiastically to build his house out of wood, and ”because he wanted to be able to change his mind about the design (or even the location) as he went along ”he would skip the foundation and generate a quick win by quickly building the walls first.

He was concerned at first that there might be a big bad wolf lurking in the forest-and that wood might not be the strongest material because the wolves in this area were notorious for blowing houses down. But the lumberjack from whom he bought the wood had assured him that he was being driven by fear, and that he should instead have the courage to build his house out of wood and to skip the foundation.

Well, he replied, half-jokingly, an agile material like wood is okay for small projects like mine, but I wouldn t want to build a skyscraper using it!

The third little pig, meanwhile, decided to build his house out of bricks . He had also thought about what he wanted a lot more and did not rush into the construction of his house. Instead he decided that, although he wanted somewhere to live, he also wanted something with a decent investment potential.

After looking around for a while, he settled upon an interesting location in an up-and-coming area, with lots of room for future expansion. In fact, he decided to build a large block of apartments that he could sell off as the area gained in respectability. He knew that his house would take longer to build than the others, but then his plans were on a much larger scale. By taking the time to plan ahead, he was confident that his property would shoot up in value very quickly ”although he was somewhat concerned that it would be another 12 years before he was finished.

Each pig s approach had its merits and its drawbacks, with the possible exception of the straw house, which ”let s face it ”only had drawbacks.

For the majority of projects, the ideal software process would be the equivalent of a wooden house, with a good foundation (because a wooden house without a foundation is just a shack ), but nothing too elaborate. However, if you re writing a safety-critical system, for example, you might want some concrete and steel in your architecture.

^{[15 ]} The first 90% is always easy. Fear might be the mind-killer, but it s that second 90% that is always the killer on software projects. To (mis)quote Marvin the Paranoid Android from Douglas Adams The Restaurant at the End of the Universe : The first 90% was the worst. The second 90%, that was the worst too. After that we went into a bit of a decline. . . .