I’ve been called a lot of things in the past few days since I had a public disagreement with many folks over the definition of Mort. On the surface, it looks like I’m a pretty “out of touch” guy when it comes to the ‘common vernacular.’ Granted, but looks can be deceiving. There’s more here. Please bear with me.
First off, I want to publically apologize to Sam Gentile. I meant no offense when I asked if he wanted MS to develop BDUF tools. It was an obviously absurd question, (OK, obvious to me, not obvious to Sam). I sometimes ask obviously absurd questions when I want to point out that the “logical conclusion” of a line of thinking will take someone where they don’t intend to go. That didn’t work on the blog. My bad.
Add to that another mistake: My reading of Sam’s message to me was probably incorrect. In a response I made to a post on Microsoft and Ruby, Sam said:
I don’t think you are getting that point. MSFT is making tools for Morts (the priority) at the expense of every other user (especially Enterprise Developers and Architects). They have nothing for TDD. And I would further contend that making these tools “dumbed down” has significantly contributed to why Morts are Morts in the first place and why they are kept there. Think VB6 and the disatrous code that was unleashed everywhere. If Microsoft took some responsibilty and created tools that advocate good software design principles and supported them then things would be different. You and Peter (which is a friend of mine) are covering the corporate butt. It’s a cop out.
Does it look like Sam is saying “Mort is dumb” or “Mort is bad?” I thought so at the time. Perhaps that was not right. I carried my misreading a bit further. I read Sam’s message to mean, “people who think like Mort thinks are errant.” In hindsight, I believe that Sam meant to say “people who work like Mort works are errant.” The difference is subtle but the result is profound. Implication: Mort is not a bad person or a stupid person, but the code that Mort produces is not maintainable, and that is bad for all of us. (I hope I got that right this time). Sam cares about maintainable code.
To rephrase, the problem is not Mort. The problem is the unmaintainable code he produces.
So my apologies to Sam.
But was I insane in my conclusions as I’ve been accused of? Did I redefine Reality? No.
First, let me put up a quadrant.
I got the axis values directly from the agile manifesto, so it shouldn’t be a surprise to anyone in the agile community.
Take a look for a minute and see if there’s anything you disagree with. One thing that may be a bit odd is the entry called “agile tool users without ceremony.” This is for the folks who use agile tools like NUnit and CruiseControl to do development, but don’t follow any of the other elements of agile development (like rapid cycles, time-box development, FDD, XP, Scrum, etc). I don’t know how prevalent these folks are, but I’ve certainly met a few.
Regardless, look at the values expressed in the Agile Manifesto. Someone who cares more about “meeting the needs of a user” than they do “following a process” would move up the Y axis. Someone who cares more about “working software” than they do “comprehensive documentation” would move along the X axis.
OK… reader… where is Mort?
Think about it.
Mort doesn’t follow lots of process. He writes code for one-off applications. Why? Because that is why he was hired, and that is what he is paid to do. He does exactly what his company pays him to do. Does he write a lot of documentation? No. So given those two variables, which quadrant does he fall into?
The upper right. The one marked “agile.”
If you wonder why a lot of development managers are unsure of the agile community, it is because this comparison is not lost on them. Any person who doesn’t care for process and who doesn’t want to write a lot of documentation can fit in that upper quadrant. Agile folks are there.
So is Mort.
I can hear the chorus of criticism: “That doesn’t make Mort agile!” Hugo is Agile. Mort is not!
I’m not done.
Mort is certainly a problem, because in our world, unmaintainable software is a pain to work with. Some folks have decided not to hate Mort but to educate him. (which is good). The subtle goal here: move Mort’s skillset and mindset: help him to value maintainable code.
If we do this, and we help Mort grow, will he keep his current job? Probably not. He was hired into his current job because he was a Mort. He was hired because his company values quick fix apps. Once our intrepid student no longer values unmaintainable code, he will no longer fit in his current positon. He will find another job. So what will the company do with the open position? They will hire someone else and TRAIN THEM TO BECOME ANOTHER MORT.
Remember, we don’t hate Mort. We have a hard time with his code. We want to eradicate his code. But the code is still being developed… by a new Mort.
There are an infinite supply of new Morts. Therefore, the solution of “educate Mort” doesn’t work to solve the problem of unmaintainable code. The solution doesn’t address the underlying reasons why Mort exists or why his code is bad. You cannot fight economics with education. You have to fight economics with economics.
Let’s look at the economics of unmaintainable code, and think about Mort a little more.
Code is unmaintainable because it’s complexity exceeds the ability of a developer to maintain it. Would you agree that is a good definition of ‘unmaintainable code?’
Rather than look at “making code maintainable,” what if we look at making code free. Why do we need to maintain code? Because code is expensive to write. Therefore, it is currently cheaper to fix it than rewrite it. On the other hand, what if code were cheap, or free? What if it were cheaper to write it than maintain it? Then we would never maintain it. We’d write it from scratch every time.
Sure, we can choose to write maintainable code. We can use practices like patterns, object oriented development, and careful design principles. On the other hand, we can give Mort an environment where he can’t hurt himself… where his code is always small because only small amounts of code are needed to get the job done.
This is useful thinking here. If you cannot make sure that Mort will write maintainable code, make him write less code. Then when it comes time for you (not Mort) to maintain it (he can’t), you don’t. You write it again.
And that is fighting Mort with economics. Soon, Mort’s skill set doesn’t matter. He is writing small amounts of unmaintainable code, and we really won’t care. Someone ‘smart’ has written the ‘hard’ stuff for Mort, and made it available as cross cutting concerns and framework code that he doesn’t have to spend any time worrying about. Mort’s code is completely discardable. It’s essentially free.
Hugo cares about quality code. Mort does not. In the fantasy world of free code, what value does Hugo bring, and where does Mort fit? Does Mort put process first or people first? He puts people first, of course. He writes the code that a customer wants and gets it to the customer right away. The customer changes the requirements and Mort responds. If it sounds like a quick iteration, that is because it is. This process is fundamentally agile.
Yep. I said it. In situations where maintainability doesn’t matter, Mort is agile. His values are agile. He is paid to be agile. He delivers value quickly, with large amounts of interaction with the customer, not a lot of process, and not a lot of documentation. According to the Agile Manifesto, in a specific situation, Mort is agile. He is also dangerous.
So we constrain him. As long as Mort can’t hurt himself and others, we are protected from him.
Of course, we can give Mort smarter tools. But that goes back to the argument that Mort is the problem. Mort is not the problem. His employer is. We train Mort. He becomes a quality programmer. He leaves. The company hires another Mort.
So what about those Morts that we cannot train? Every time we try to shove great tools at “untrainable Mort”, we don’t get “smarter Mort.” The tools get used by other people, but Mort ignores them. We get faster and better code written by the people who care about faster and better code. Mort doesn’t care. He is not paid to care. He is paid to write code quickly, solve a quick problem, and go on. His code is not maintainable, and THAT IS OK, because he can write small amounts of code (or no code) and still deliver value.
So how do we pull this off? How do we allow Mort to write small amounts of code so that we don’t care?
We’ve been trying to solve this problem for a decade or so. We tried creating an easy drag-and-drop environment, but it didn’t protect us from Mort. We tried creating controls that do all the hard stuff, but it didn’t protect us from Mort.
Now, SOA and the Web 2.0 space has opened up a whole new world for Mort to play in. Generation Next is here, and finally we may be a bit closer to an answer.
Possible Answer: We can have Mort consume a service. He can’t change it. He can’t screw it up. But he can still deliver value, because often 60% of the business value is in supporting individual steps in a business process. Those steps are carefully controlled by the business, but honestly, are not that hard to put together. It’s a matter of “step one comes first, step two comes next.” As long as the details of the interaction are hard to screw up, we are protected from Mort.
Here’s the cool thing: Microsoft didn’t invent this iteration. This little bit of “Mort defense” came from the integration space (think ESB) combined with great thinking from the web community. This approach is not something we thought of, but it works to the same ends. This new way is based on SOA principles and REST protocols (what some are calling WOA or Web Oriented Architecture).
Web 2.0 and Mashups are the new agility. Write little or no code… deliver value right away.
And in this space, Mort is agile. Heck, we even like him.
And in case you are wondering why I don’t hate Mort… this is the space I live in.