This is an interactive slide deck of my talk at Agile India 2013. I explore the interplay and gap between the architect
and the manager. Along the way, I point out some agile landmarks
that we need to stop and reconsider. I will also highlight some tweaks
that I make to find balance, finding a thread to narrow this divide.
Tag Archives: architecture
Stay in bed or come to SGZA
I will be hosting a 3 hour session at the South African Scrum Gathering titled “Live your principles or stay in bed”. You can read the abstract here. In my opinion, there is far too little focus on software development itself in Scrum. So, this is unashamedly a developer session. I will be present various snippets of code, and we will “live our principles” to transform the code into something that is less messy.
I often hear developers, and managers too, saying “It’s so much easier without, so why bother?”. Well, design is hard. Applying principles for life is harder. But if you are professional developer and have a conscience about your design, your code, and your product then “an easy life without principles” is not an option.
If you are planning to come along, bring your laptop with your development environment. I will likely have code samples in Java, C#, Ruby, Javascript, and even, yup, Basic (well, maybe). All the samples should be very readable and you could easily translate them to something equivalent in your language pretty easily. Better still, bring some of your own code along, that you want to share.
In reality, this is stuff that Scrum does not teach you, but need to know to avoid Scrum burnout. Looking back, I should have done something like this sooner.
You can’t let Scrum die
In my last post I said we should let Scrum die. We can’t let Scrum die. It doesn’t behave like that. It will only die off its own accord if we die first and then it dies because it has no reason to exist. So you got to kill it. Here’s why (again?).
Software development is about people and the way people work alone and together. People create code in software development. Without that code, these people don’t exist; they have no purpose. Code is the creation of the people, and people live off this code. When the code is good, then life is good. When the code is poisonous, then people start dying slowly. When the smell of death is in the air, they look for help. Some stare into the mirror called Scrum. They see themselves and the way they behave. It’s an ugly sight. They realise that they should behave better. After all, software is about the way people work alone and together.
Regularly looking into the Scrum mirror, they improve their behavior over time, and everyone is happier than the moment before. That’s a nice view. Just look in the mirror and it looks good. Very rarely do they also look again through the window into the fields of code that feeds them. The poison is still coursing through their veins. They will die, eventually … by the host that they created that was supposed to nourish them. The only way to survive is to deal with the fields of code. Get rid of the toxins. There are two fundamental ways(*) that you can get rid of toxins: (a) eliminate duplication, and (b) make the code as you wish it to be.
If they just stare into the mirror and hardly ever look out the window, they will just exist on the plateau of complacency. In order to avoid that state of being, they need to focus on the fields of code. The urge to look in the mirror is strong, and as useful as it was, it becomes a very unbalanced state of existence.
So, look in the mirror, but look through the window too. Create fields of code without toxins so that you provide nourishment for the next person. That is ubuntu coding.
Actually, the only mirror you need is the person working next to you.
(*) Think deeply about these two fundamental things and try it out. Everything else will fall into place from this. For example, the act of eliminating duplication forces you to consider where to locate a single piece of code, how it should be used and where it can be used, etc. That is design and architecture. With duplication, you don’t need to consider any of those things. That’s toxic.
Let Scrum die
I live in Cape Town, South Africa. Apart from the great beaches, a mountain in the middle of the city, good food, and good wine there is a feeling of enthusiasm for agile software development in this town. It’s been around for a while but really started getting all hot and sweaty with the Scrum wave. I estimate that it’s been at least 2 to 3 years since some teams in Cape Town adopted Scrum. Of course, there are teams adopting Scrum in this community every year. That’s all good, but I’m afraid it’s shaping to be just like Table Mountain.
Regardless of the hyper-performing tagline of Scrum, each team settles down to something with which everyone is comfortable. The big change that has happened is that of changed behaviour. Scrum does that – it alters behaviours. When everyone plays by the rules (i.e. they behave consistently) then you don’t have chaos. It’s better than better – it’s just nice! It is very comfortable. But I see signs of chaos not far away again. This is what is happening and it is almost without exception here in Cape Town. Some are off the table top already.
Let me make the Scrumvangelists feel better for a brief moment. Scrum won’t kill you – directly, but your adoption of Scrum can kill you if you ignore one thing – your code base. It is a code base out of control that leads to certain death, and Scrum won’t be the saviour this time. Bringing your code base under control is not easy. It is all about architecture, design and changing your style of development to live the principles that end up characterising good code. I don’t need to tell you what you need to do. It’s been told so many times – TDD, refactoring, continuous delivery, single code base, etc. At the code face it’s SOLID and DRY and lots more.
The plateau of complacency is an interesting place. We may think we are collaborating but in reality we have just found a way to work together without causing chaos. I call it co-operation. It’s just keeping chaos under control so that we can make the sprint, again and again and again. A sure sign of being on the plateau is when we can’t get rid of our Scrum master. When we work the Scrum master out of the system, then the team will need to take on more on it’s shoulders.
A major limiting factor to get off the plateau will be the people on the development team. Hyper-performing teams have talented developers(*) that are able to design and express that design in code without breaking their principles. A team that is unable to bring a code base under control will compensate by leaning on a scrum master for support.
In the journey of dramatic improvements to bring your code base under control, there are few things that you should take notice off.
- An architecture will emerge that supports the design of the resident parts. Things fit together beneficially.
- The code base will get smaller and the team will shrink to about 2 or 3 people.
- Each developer will take on greater responsibility and will find it difficult to break core principles. The act of living those principles will result in a values that don’t need to be listed on a poster on the wall.
- The scrum master will become redundant.
- The product owner will do more by working directly with the developers.
Then you won’t need Scrum, because the code base is under control, developers represent the interest of their customers, and the bottleneck is now at the customer.
Am I being idealistic? No, it’s about pragmatic decisions and the pursuit of freedom. It’s hippie Scrum.
(*) By talented I mean developers who have the ability to communicate, share, solve problems simply and elegantly, and can sniff out bad design and architecture. Talented developers are not code monkeys that can churn out code. Their single differentiating trait is the ability to design well and express that design in code.
RESTing at Øredev
There was quite a bit of REST chatter at Øredev last week. I sat in on the REST in Practice tutorial by Ian Robinson and Jim Webber (if you have not read the book they co-authored, then do – it’s really well written). There were a couple of things that these two guys cleared up for me, in the tutorial and in conversation during the week.
Application state is in the head of the consumer, not the provider of the resources. This suggests that we should be able to recompute the state of application at any time. If we can recompute the application state, then we don’t need to explicitly implement the entire application state machine in the provider, nor the client.
You may start off with modeling an application state machine on paper and discover the life cycle of resources. Implementing this is then simpler because we are only need to implement the lifecycle of the resource, not the entire application state. The way the consumer drives the state machine is just be reacting to available transitions in the representation of a resource. Now you give the provider the freedom to change the application state machine and the consumer will react to the new state machine by discovery. That is significant.
Use hypermedia to refer to yourself. This came up in the tutorial because I objected to a resource including a hypermedia link to itself, regardless of its state. To me, it seemed to have little value because you already have the representation of a resource in a particular state, so why include hypermedia for itself. For example, this is what a resource will look like without a link to self.
<Order> <id>823763</id> ... <links> <link rel="pay" href="http://example.com/payment/823763"/> </links> </Order>Now, if I want to GET the original order resource, I would need to know that there is some URI that includes the id of the order. And, so, we end up publishing a URI template such as
GET http://example.com/order/{id}If we include a link to self, then the representation looks like this.
<Order> <id>823763</id> ... <links> <link rel="self" href="http://example.com/order/823763"/> <link rel="pay" href="http://example.com/payment/823763"/> </links> </Order>Look Ma! I don’t have to expose a URI template anymore. It’s all discoverable. That is significant.
REST support in WCF is heading in the right direction. I also listened to Glenn Block’s talk on his team’s work on HTTP and REST support in WCF. It’s still early days but I think they are paying attention to experts in this space and giving priority to the developers that will use it.
In the past you would have to map a very specific, template based HTTP GET operation to a method like this (excluding the additional endpoint configuration too!)
[WebGet(UriTemplate = "{id}")] public Contact Get(string id, HttpResponseMessage resp) { ... }What Glenn showed was a method signature that resembled the HTTP operation on the resource.
public Contact Get(string id, HttpResponseMessage resp) { ... }Sure, it’s using a lot of convention over configuration to get rid of the attributes. Now that may not seem like a big deal, but I do think that it is moving the HTTP abstraction down to a level that is more resource friendly. When you are building a RESTful architecture, then you do think quite naturally in terms of the resources and their allowable HTTP operations for obtaining state or triggering a state transition. By moving away from mapping HTTP operations to a service contract, it introduces the necessary mental shift from RPC to Resources. And that is significant.
This mess started long, long time ago
My son borrowed Asterix and Cleopatra from Claremont Library last week. It’s been ages since I read anything from that series. But page 2 really had me chuckling. There is an image of the page online, but it’s bit hard to read. So, here’s the dialog.
The scene: Cleopatra has been challenged by Julius Caesar to build a grand palace that will prove that the Egyptians are an advanced nation. She summons Edifis, her architect.
Cleopatra: Edifis, I have summoned you because you are the best architect in Alexandria – which is isn’t saying much.
Edifis: Oh!
Cleopatra: Don’t answer back! Your buildings are flimsy. You can hear every word the neighbours say. The ceilings fall in!
Edifis: It’s these modern materials… Actually, what I really want to do is build pyramids and …
Cleopatra: Silence! You have just three months to make good. You are to build Julius Caesar a magnificent palace here in Alexandria.
Edifis: Did you say THREE MONTHS?
Cleopatra: If you succeed, you will be covered in gold! If not, you will be thrown to the crocodiles! You may go.
(Edifis walks out)
Edifis: (thinking) Three months! I’d need supernatural powers to do that! I’d need someone who can work magic.
Edifis: (shouting) Got it! I know the very man! He can work magic!
Now, where have we seen that before?
(And just get the original book and read on about mule-driving the slaves to haul huge blocks of stone … classic!)
Architecture in an Agile World
Next week, I will give a talk at the JCSE Architecture Forum entitled Architecture in an Agile World (or maybe it’s the other way around). It’s not a new topic but since I visited it at a MagmaTec conference late last year, I have updated my thoughts a bit. The angle is also different because I want to explore what it means to be agile in process, and agile in practice and how that relates to understanding a problem and carving out solutions. Often, it is actually a choice to find a solution that is just and that is able to balance the various tensions.
But, I think I am equally excited at the possibility of seeing some familiar faces again in Johannesburg.
I wanna hold your ha-a-a-a-a-a-and
Do you remember that catchy Beatles song?
Oh yeah, I´ll tell you something I think you'll understand When I say that something I wanna hold your hand I wanna hold your hand I wanna hold your hand
So what made me think about this? That frustrating construction of the new M5/N1 interchange in Cape Town!! When you’re sitting in traffic, you can’t do anything but look and think. And I’ve seen this scaffolding get taller and taller and wider and wider and longer and longer and more and more people appear on it each day.
I know that one day, they will remove the scaffolding and the concrete will just hang there in mid air on those massive pillars and walls that they’re busy building, and I won’t be sitting in traffic any longer, and it will all just work.
What a shame that software is not like that !! So many people get turned on by scaffolding. And The Beatles sang on …
And when I touch you i feel happy, inside It's such a feeling That my love I can't hide I can't hide I can't hide
And just like the M5 construction, so much scaffolding gets built, and so many people climb on. But then, they don’t climb down. And they don’t tear down the scaffolding. And it just stays there mashed in with the concrete bits. And then they ask people to use it. And it takes strain and then it’s a performance problem, or a load problem, or it just crashes down.
I do use scaffolding, but most of the time it’s in a spike and more often it’s in a test, just to get me over my point of fear. Deploying software with scaffolding is just dangerous and negligent. I really don’t want to drive my car over the M5 interchange while those thin steel pipes are holding up the concrete slabs.
But above all of that, the most important scaffolding is social scaffolding. It’s better to provide human scaffolding to support each other on a team that is focused on delivering quality software. It’s worse to plug in weak struts in the code base that will just collapse when the next developer builds on top of it. Very un-ubuntu!
So, the Beatles song still holds true, but only for social scaffolding.
Yeah you, got that something I think you'll understand When I say that something I wanna hold your hand I wanna hold your hand I wanna hold your hand I wanna hold your ha-a-a-a-a-a-and
What’s worse than BIG DUF? A BIG DIC!
Most agile people say big designs up front rarely pay off. You spend so much time doing design that you delay the opportunity of feedback from real, working software. But I sometimes do BIG DUF. It’s not that the design is big, it’s the problem that is big. So I need an up front big picture with just a few big parts.
It helps me conquer and divide.
That’s not a bad thing. What I find really painful is casting the design in concrete. When your design is cast, then your mental state is already cast in concrete too. And that means that it is a lot harder to do the right things. So, more gets added to the concrete slab and it’s real hard work to break anything off. When I have a BIG DUF, I often look at how to reduce it, rather than increase it.
I don’t think it’s wrong to have a BIGDUF, it’s worse if you have a BIGDIC (BIG Design in Concrete). That concrete block will hurt you later … a lot.
In other words, the size of a BIGDIC does not matter, it’s the rigidity that’s the problem (— That’s so lame, I could not resist!)
Mapping Steve’s Mind and More
If you hate reading lengthy blog posts and dig the mind map view of the world, then add Steve van der Merwe’s blog to your feed gadget. What I really like is his short quick observations and great views about software development. But for me, it’s even better that I get to speak to him regularly, in person. If you’re in the Cape Town area, make a point of finding him and chatting to him. He makes ubuntu real.
f3yourmind 