Once upon a time, in a Company far away,
there worked an ambitious and talented young software architect, who, for lack
of a better idea, we shall call Luke. Now Luke absolutely loved his job. There
was no greater satisfaction for him than designing an architectural framework
that could accommodate any requirement that a Product Owner could possibly
need. And his achievements did not go unnoticed in the Company. So it was one
afternoon that he was called into his boss’s office and was told of his new
Mission: defining an architecture for a ground breaking Application that would
change the industry in which the Company operated, and as a side effect would
bring world peace. Or something equally noteworthy.
Naturally Luke dived into this Mission with
his known zeal and enthusiasm. He had long talks with representatives from marketing
and sales about the requirements. He discussed these with some of the senior
developers in the Company, a group that would eventually, together with a few
Testers, become the Team. One of the marketing representatives was eventually
appointed Product Owner, and in the course of a few weeks, Luke, who had
superior pattern recognition skills, noted that all requirements Product Owner
had come up with could technically be reduced to Triangles. Triangles of many
different sizes and types, but Triangles nonetheless. And so Luke decided that
the basic building block of the application was going to be the Triangle, and
that a Framework was to be built that could accommodate any type of Triangle,
either by extension, or by rearranging the already delivered Triangles. With
this strategy, he achieved scalability, extensibility and maintainability in
one master stroke. Upon discussing his plans with the Team, Lead Developer
observed that this Framework would be costly and time consuming to build up
front, and that it could only deal with requirements that in some way could be
reduced to Triangles. But his arguments were refuted when Product Owner stated
that no requirements other than Triangles were considered or even deemed
necessary for the success of the project. As far as the budget was concerned,
building the Framework up front did not have a negative impact on the business
case, in fact, the time spend on this would be won back later in the project
when new requirements would be implemented faster than without this Framework.
And so, after the Company investment board
had agreed to the plans and the budget, work began on building the Framework.
The first version took six months to build, and a prototype of the Application
was made with it that could indeed accommodate the first requirements listed by
Product Owner to satisfaction. This convinced Luke and the Team that the chosen
strategy was the right one. Over the course of the next year, many different
Triangles were added to the Application, all within the context of the
Framework. Work now progressed at breakneck speed, and the commercial rollout
of the Application was an astounding success. Yes, life was great. Luke had
printed the Framework Diagram on glossy A2 paper and hung it above his bed in a
luxury frame. His beautiful wife looked up to him in devout admiration and his
young children were more obedient than ever. After a well-deserved vacation, paid
for with the substantial bonus he had received from the Company after a glowing
performance review, Luke drove to his office thinking about the great things he
intended to do with the Framework of Triangles. It might come in handy for
other projects the Company would execute. But first order of business would be
a backlog grooming meeting where Product Owner would start explaining and outlining
some new requirement that had come up during Luke’s holiday. Confident this too
would be reduced to one or more Triangles, he entered the meeting room, where
the Team and Product Owner were already present. The new requirement was lying
on a central table still hidden under a silk drape. Salutations were exchanged
and once everybody sat down the meeting started. Product Owner held a short
presentation about the latest user feedback, market opportunities and usage
figures, and then proceeded to pull away the drape from the new requirement.
Before the eyes of everyone lay a, immaculate, bright, shining, perfectly round
Circle.
It took a few seconds before Luke realized
what he was looking at. This was not a Square that could be diagonally cut to
make it two Triangles, or any other Polygon that could be reduced to a set of
Triangles. They had dealt with those before, although Product Owner didn’t seem
to understand why the estimates for these always came out quite high, and why
so much discussion was always needed on the correct way to split these Polygon
requirements up. But a Circle was a different beast altogether. There was just
no way to divide these in Triangles without losing material at the outer edge
of the Circle.
It was Lead Developer who broke the silence.
“Listen”, he said to Product Owner, “Just how important is it that this Circle
is implemented as a perfectly round Circle as opposed to an approximation like say
an Octagon or Dodecagon”?
“What do you mean”, answered Product Owner,
“The requirement is clearly a Circle. So what I want is a Circle, not an
Octagon or Dodecagon. I would have asked for those if I wanted them, but the
user feedback indicates a strong need and market opportunity for Circles, so I
want a perfect Circle. That’s the whole point of this requirement. How many
story points you think it will take”?
“Well”, said Lead Developer, “I guess that
depends on the architectural approach we take”, and he directed his eyes to
Luke, who was feeling more uncomfortable by the minute. The Team and Product
Owner looked to him with great expectation.
After 30 seconds of deafening silence, Luke
got himself together and said “You see, Product Owner, our architectural
Framework doesn’t support Circles. It was made for Triangles, and we can cut up
Squares and Rectangles and other Polygons into Triangles without having to
throw away anything, but with Circles, or in fact with any Shape that has
curved edges, this will not work”.
Product Owner looked confused. “I don’t
understand”, he said, “When we started this we explicitly stated that we needed
a flexible architecture to accommodate all sorts of requirements, and we have
done so with Squares and Rectangles and Pentagons, so how come a Circle won’t
fit”?
“Well”, said Luke, “The Framework is
flexible in the sense that we can accommodate all sorts of Triangles, and this
is what we in fact agreed on early on. The fact that we managed to cut up
Squares and the like into Triangles doesn’t mean that the Framework natively
supports these shapes, just that we found a workaround that is invisible to the
end user. Functionally, yes, they’re Squares and Rectangles and whatever, but
in the backend it’s all Triangles and nothing else. I mean, we have talked
about this extensively during several Grooming and Planning meetings where we
discussed these non-Triangle requirements, don’t you remember”?
Product Owner was becoming somewhat
irritated by now. This was not something he could report to his own boss, the
VP of Business Development for the Company,
without consequences. The Circle was a vital part of the product strategy for
the next 12 months. Just two weeks earlier, the Competitor had shown a preview
of its own Application and the Circle was to be central to their strategy. So
quick delivery of the Circle was instrumental to stay ahead of the Competitor.
He estimated the Company would have no more than 4 sprints to beat the
Competitor to market with the Circle, and now this supposedly stellar Architect
was telling him something as simple as a Circle couldn’t be done? What were
they paying him for?
“No”, he said, “I don’t remember and I
don’t understand. After all, I’m not a technical person, that’s your job. I
mean, if you can accommodate Squares and Rectangles and Pentagons, and you’re
even proposing Dodecagons now, how hard can it be to accommodate a Circle? I
can’t believe the difference is that big”.
“Let
me answer that”, interrupted Lead Developer, “You see, as long as the Shape has
only straight edges and corners, we can cut it into Triangles. The more corners
it has, the more cuts are needed to do that, that’s why implementing a Pentagon
is more expensive than implementing a Square, which in turn is more expensive
than implementing a Triangle, which doesn’t need to be cut at all. But a Circle
can be thought of as having an infinite number of corners and infinitely small
edges, and thus needing an infinite number of cuts to get an infinite number of
Triangles, and thus the cost would be infinite as well”.
“That is ridiculous”, fumed Product Owner,
“The way I see it, a Circle has no corners at all, and only one edge, so the
cost of implementing it should be even cheaper than a Triangle as per your own
reasoning. Are you trying to pull my leg”?
“No, no, not at all of course, I’m dead
serious. In the context of the current Framework, implementing a perfect Circle
will have an infinite cost, which is another way of saying it’s impossible. The
point is that the single edge of the Circle is curved and not straight. That’s
what makes it so expensive”.
“Sure, but it is only one edge and there
are no corners. That should compensate for the curvy nature of the single edge,
shouldn’t it”?
This conversation was getting nowhere, Luke
realized. He took the word once again. “Look, we could make a big enough triangle
so that the Circle will fit inside it. But there are a few drawbacks: First,
there will be empty spaces between the outer edge of the Circle and the inner
corners of the Triangle. So this particular Triangle won’t be as strong.
Depending on where in the Application we put this ‘Circle inside a Triangle’,
this lack of strength will cause more or less instability in the Application,
for that we would need to do a detailed impact analysis. Second, since it is
weaker than other Triangles, we can’t build on top of it. That means we can add
one or maybe two ‘Circles inside Triangles’ to the Application, but that’s
about it. It will reduce extensibility and scalability”.
“I have another suggestion” said Lead
Developer, “Why don’t we just build the Circle next to the Triangle Framework?
In that way the stability of the Application isn’t compromised and we can
continue building on top of it. Only drawback is that the Circle would be a
sort of stand-alone feature, not fully integrated into the application”.
“That’s unacceptable”, said Product Owner,
“One of the acceptance criteria is that it works seamlessly with one of the
Rectangles and two Pentagons we added to the system 6 months ago. A stand-alone
Circle would be very user unfriendly”.
This was pondered for a moment. “Well”,
said Lead Developer, “Then we could build a second Framework based on Circles,
and re-implement the two Pentagons and Rectangle in this Framework as well,
although they won’t be 100% the same as the Triangle based ones. But this too
will be costly, and we would need to maintain two Frameworks instead of one.
And we would need to find a way to hide all this from the end user”.
Luke started to get a severe headache. His
beautiful and elegantly designed Framework was butchered and compromised right
in front of him, by the very people who had admired and approved of the
sophistication of the design. Although to be honest, he had never fully trusted
Lead Developer in this. And was it just his imagination or did he note an ever
so slight smirk on his face? Anyway, it seemed to him that there were several
options, none of them good:
1.
The reduced requirement option.
Settle for a Dodecagon instead of a Circle. This would be relatively cheap, and
would not compromise the application in any way. But it would reduce the
business benefit for the Big Important Customer. Maybe amount of corners and
edges could be raised further to decrease the loss of business benefit further,
but that would also raise the cost of implementation.
2.
The quick and dirty option. Implementing
the Circle inside a Triangle. This would also be cheap, even cheaper than
option 1, but it would lower the business benefit as it would come over as
rather strange to the end user. It would also compromise the application
integrity, making this option not only cheap but also dirty.
3.
The second Framework option.
This would be expensive and time consuming, but it would be a lot better from
an application integrity point of view. It basically boiled down to duplicating
some parts of the Application in a different Framework.
4.
The total refactoring option.
Build a new Framework that can accommodate any kind of Shape, and then migrate
the existing Application to this Framework. This would be the best option from
and architectural point of view but also the most expensive and time consuming.
After listing these four options to Product
Owner and the Team, the mood of the meeting had turned rather sour. Product
Owner didn’t look happy at all. None of the options were acceptable to him. He
didn’t want to lose the advantage over the Competitor just because of some
incomprehensible technicality. Luke himself kept wondering how this situation
had come to be. The meeting ended with the agreement to inform the Project
Steering committee and senior stakeholders. Product Owner parted with a cool
handshake to Luke. Then Luke reluctantly went up to the office of his boss to
inform him of the news. But he was already aware. His salute was ”We will replace you with
another Architect” …
Soaked in sweat and heavily breathing Luke
woke up, at first not knowing what had happened and where he was. He was still
shaking when he climbed out of bed and went into the bathroom for a glass of
water. Looking into the mirror, he realized it had all just been a horrible nightmare. In fact, the Team had
delivered a first version of the application in 3 Sprints implementing just 2
Triangles. In Sprint 4, they had implemented a Square by adjusting the
architecture such that it could adapt to any Shape. Emerging Architecture at
its best. A Circle would not be any problem at all if Product Owner would
require it, just a little refactoring.