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. 

Agile 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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

31 thoughts on “Mort and the Economics of Unmaintainable Code”
  1. And who is going to write that service that Mort consumes?  In many organizations, what Mort cannot find or access quickly, Mort (or his similarly Mort-ish colleague) creates and/or re-creates.  How exactly do you see SOA (+/- tools) changing this behavioural pattern?

  2. It is very hard for people to imagine that some software is, in fact, disposable.  Maintainability comes at a price, and there are times where the correct business decision is to value expediency over maintainability.

    I once wrote a piece of software that was used in production… exactly… once.  The purpose of it was to generate a set of word documents translated from html in order to provide a one-time snapshot of the contracts that were being aquired from an aquiring firm.  The systems we were pulling the data from were going away in 3 weeks, as the aquiring company was based on an entirely different app stack than the old one, and had no desire to work with it at all, regardless of it’s code quality.

    Had I spent extra time writing a full set of unit tests, automated user acceptance tests, and so on, I would have been wasting the time, and therefore money, of the client that needed a one off solution.

    This kind of scenario happens more often than most capital A agilists tend to want to admit.  Not all code lives forever.  Some code doesn’t live until the end of the month.  And that’s ok.

  3. …Microsoft might stop trying to convince Mort’s boss that Microsoft’s tool actually deliver the indescribable value not described at the demo of Microsoft’s tools to Mort’s boss.

    We all have a role to play.  We’re out in the field trying to undo the damage comes when marketing imperatives trump meaningful agility, and Microsoft has a giant role to play in contributing the the circumstances that are a significant cause of the existence and persistence of Mort.

    The company could still be successful without the assumption-driven development-styled tools, but I think that it has since fallen prey to the very fear that it mongered in effort to achieve great swaths of its dominance.

    There’s a whole heck of a lot more to being on an effective, cross-functional agile team than the treatment you’ve laid out here.

    I would agree that based on your perspective of agile development that Mort can be thought of as agile, but it’s a bit of a shallow treatment of agile development.

  4. The graph needs a 3rd (or more) axis.  More might be here with intentions, but his education will lead him to develop some software that will rot even before it’s finished (think 30000+ lines of code for something non-trivial).  The uneducated practices will focus on working software, but the lack of discipline will cause development to grind to a halt because of complexity and lack of quality that the product might not even be delivered.

    This works great for small things, but Mort also develops larger things.

    The dream of making code free or close to it is tempting, but can it ever happen?  If so, then why give us professionals the same tools meant for Morts?  Shouldn’t it be a different set of tools?  

    In the end, I do blame management for all things wrong in their own software shops.  They don’t know how to tell the difference in software professionals, and that is _their_ fault.

    Interesting post.

  5. @Nicole,

    Excellent question.  The real value of creating a services layer is to hide the hard stuff in the services and then allow the composition to happen at the Mashup / SO Composition level, keeping Mort out of the services altogether.

    So to answer your question: Mort does not write the services.

    Of course, that doesn’t mean that services will only be written by someone who cares about quality… at least not yet.    

    The fiction of my scenario meets reality when we start discussing the skill level of the professional developers charged with writing the services.

    I have hope though.  I’m proposing a framework for use within the behemoth that is Microsoft IT for creating a framework of services that we can expose to open source.  That framework would allow services to not only be created internally, but created externally as well.  Our company could literally purchase the ‘create order’ service from one company and the ‘create invoice’ service from another.

    So the question of who creates the service becomes even more interesting… if we start competing on the quality of the services, then Mort’s service loses out.  

    Once again, economics wins.

  6. Nick, I hear what you are saying about providing services written by Hugo, Elvis or Einstein … and that you are proposing that Microsoft start moving that way.

    But do you really see Microsoft doing that? They have a fairly fundamentally anti-service approach to a large proportion of their codebase – an obvious example would be the Enterprise Application Blocks.

  7. @Jeffrey,

    30,000 lines of code is not free.  If we make someone write that much code to solve a business problem, then the world I’m hoping to achieve has not yet come to pass.  Mashups shouldn’t require 30,000 lines of code and neither should compositions.  I’m thinking 500 lines of code.

    As for the tools: the parts of Visual Studio aimed at making Mort successful are not the parts of Visual Studio that you will use.  We’ve tried selling two tools, one for Mort and one for you.  

    We’ve discovered something.  Mort’s manager doesn’t want to pay for a license for Mort’s tool, and another license for yours.  He wants one liscense, and then he can hire the person he needs to solve the problem.  More flexibility for him.

    So we need to put the Mort features in the same tool.  You are free to ignore them.  The environment works as well as any other IDE for professionals.  Mort’s tools don’t get in the way.

    Honestly, folks who say that Mort’s tools get in the way are folks who are using Mort’s tools but trying to do the job of a professional developer.  Stop it.  Do the job of a professional developer without using Mort’s tools.  Reset expectations.  You are not SUPPOSED to be as productive as Mort because you are solving unconstrained problems.  

    We go where the market goes.  We’d be foolish not to.

  8. @Casey,

    The application blocks are designed to be infrastructure within the stack, and there is a newer version that is cleaner and better integrated.  I think the AB has come a long way.  That said, I’m much more excited about the service factory than I am about the application blocks.  

    And, yes, services are BIG inside Microsoft.  Did you know that Microsoft Office Sharepoint Server (MOSS) is service enabled out of the box?  What about WCF and the fact that most aspects of the contract are declared in configuration, not code?  Very powerful.  Very service oriented.  Cutting edge.

    We’ve been snapping services onto every place where it makes sense to allow remote user interfaces (with a few notable hold-outs).  

    In fact, Microsoft just released an ESB toolkit on Codeplex last month (CTP1).  Take a look at http://www.codeplex.com/esb for details.  It is Biztalk based (so don’t ask me how we can call it an ESB) but it is still a fairly solid example of movement in the right direction.

  9. @Nick, you say: "Honestly, folks who say that Mort’s tools get in the way are folks who are using Mort’s tools but trying to do the job of a professional developer.  Stop it.  Do the job of a professional developer without using Mort’s tools.".

    That’s an interesting observation, but then I’d ask one thing: Since a lot of VS these days seems to be then squarely aimed at Morts… then what development tool does MS have for the non-morts? 🙂

  10. You are on the right path Nick; frameworks and services are definitely a starter in getting the code that Morts write to have more predictability and a better chance to be maintainable in the long run, and to have less of it!

    In a large enterprise though, I have seen that you need to provide a "platform" not just frameworks and un-managed, un-architected services to have long term success. As one commentor stated "your thesis works for small things" but starts to break down on larger efforts, more mission critical efforts.

    There are two key components I believe that turn frameworks into platforms.

    Platform Component – These are your guiding principles of your architecture style(e.g. standardization, abstraction, virtualization, loose coupling etc..), the processes (think governance over what gets built) and organizational makeup (people working in well defined roles, accountable for well defined things).

    Enablement Component – These are your best practices, reference implementations and most important of all the mentoring of Mort by your architects to enable him to be successful delivering solutions on the platform. The reason why so many Morts cringe, and many times rightly so, about architecture or governance is that we haven’t provided the enablement component for them to be successful!

    Where I have worked, the Platform Component is usually an afterthought or nonexistent.

    The Enablement Component is sometimes there, but it varys from group to group. Most often Mort is on his own to figure out how to best solve the problem at hand and that is when you get 30000 lines of code.

  11. @Steve

    You are a wise man, Steve.  Send me an e-mail using this forum (if you get this message).  I’d love to share ideas with you and get feedback.  I working along the lines of what you describe, to a point, but my system is constrained in a different way.

    — Nick

  12. It appears that I disagree about architecture with a fair bit of my industry. I’m enjoying the though exercise of trying to find a middle ground on my views. It’s this post, Mort and the Economics of Unmaintainable Code, that…

  13. @Tomas,

    VS has tools within it.  Some tools are for Mort.  Other tools are for you.  All under the covers of Visual Studio.

    It is true that Mort’s tools are visible.  They do a lot to sell Visual Studio, so they get headline space.  The other tools are there.  Look for them.

  14. Mort as an agilist is the most disingenous argument I’ve see for a long time.

    Your quadrant is fundamentally unsound as it presupposes or in respect of the axis. This is a total misreading of the agile manifesto. Agilists value tools and processes. They just value Individuals and Interactions more and recognise that there are tradeoffs.

    Agility doesn’t happen through the absence of anything. Agility happens by adopting processes and practices that support the principles of the manifesto. Mort fundamnetally doesn’t do this so cannot be agile.

    There are also no such things as agile tools. There are tools that support practices that are used in agile processes. That doesn’t make the tools agile. They’re just tools.

    Whatever toolset you use if you don’t follow the manifesto you’re not agile. Simple.

    Try reading it again with an open mind and no agenda.

  15. @Ian,

    I expected to get feedback like yours, so I’m not surprised.  

    You may be surprised to hear this, but I’m an agilist.  I’ve been a certified ScrumMaster for a couple of years now, and I participate in agile forums and discussions within Microsoft.  I’ve led design pattern study groups, and fostered the adoption of NUnit in dev teams.  

    If you read my blog, I have entries on Feature Driven Development, Scrum, Unit testing, etc.  

    If I have an agenda, it is in _support_ of agile software development.  We are on the same side.

    I would like to look at one thing you said: "Agility happens by adopting processes and practices that support the principles of the manifesto."

    I believe that I made the case that the processes and practices that most typical Morts follow ALREADY support the principles of the manifesto.  He doesn’t need to adopt anything.  He’s already there.  That is Crystal Clear (pun intended).

    I think you made it clear that you disagree.

    Let’s find that point of disagreement.

    Instead of telling me that Mort doesn’t follow the manifesto, I’d like it if you’d tell me what "additional value statement" that you would add to the manifesto that would differentiate you from Mort… where he would fall to one side and you would stand on the other.  

    — Nick

  16. I don’t think you’ve made the case at all. Mort isn’t in to process of ANY kind. Mort isn’t into design of ANY kind.

    Mort is fix-it man. He’ll do the minimum, quickest necessary to make something work. He is the essence of QaD. In some cases that might be just what the organisation needs. Just don’t pretend its good software or will bring long-term benefit. Its a short-term fix to an immediate problem. No more. No less.

    It isn’t a question of adding anything to the manifesto to differentiate Mort. Its a question of evaluating Mort’s behaviour against the principles.

    For example, take the principle "Continuous attention to technical excellence and good design enhances agility". Does Mort apply this principle? IME definitely not. He is not interested in technical excellence or good design.

    How about "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts

    its behavior accordingly". You can apply this to individuals just as much as to teams. IME Mort is not into self evaluation or identifying ways to improve.

    I have come across lots of people who claim to be agile or follow agile practices. In a lot of those cases they were using agile as an excuse not to do things they didn’t like. I don’t believe in that kind of agile. Using tools that are designed to support practices used inagile processes doesn’t make you agile. You can do unit testing in BDUF. The first ever commercial project I worked on, nearly 25 years ago, had a full suite of unit tests. It also had a full detailed specification written up front.

    IMO truly being agile requires a level of commitment and introspection that many people find difficult. You have to be ready to evaluate what you are doing at any time to find ways to improve. You have to be brutally honest with yourself and your team as to what is good and what is not. When looking for those improvements you can use the manifesto and the principles as a basis for evaluating and comparing potential improvements in order to understand the tradeoffs.

    I don’t understand why you need or want Mort to be agile. I don’t think it does your credibility any good. I have read your blog and there is a lot of good stuff there. I just wish I understood what you are trying to achieve here.

  17. >>Did you know that Microsoft Office Sharepoint Server (MOSS) is service enabled out of the box?  <<

    Indeed … in fact I’m busy trying to get it to talk happily with K2, WebSphere, a few databases and a document management system, yet to be decided.

    >>What about WCF and the fact that most aspects of the contract are declared in configuration, not code?  Very powerful.  Very service oriented.  Cutting edge.<<

    WCF is a good step forward – but essentially WCF is about eliminating applications needing to know about the transport protocol, and letting them concentrate on the message. To its credit, it leaves the message to be dealt with by other things (unlike Web Services using SOAP, for example).

    I would have used BizTalk as a better example of MS embracing services though.

    >>We’ve been snapping services onto every place where it makes sense to allow remote user interfaces (with a few notable hold-outs).  <<

    Indeed, but there are services, and there are services.

    A service in an SOA architecture is very different to a web service providing RPC functionality, and both differ greatly from COM or remoting services.

    At the most basic level, which is where Mort lives – a service is just a remote procedure call. And that is where most MS ‘services’ reside too.

    To answer the "additional value statement" … how about …

    "Understanding the domain over trusting that others did."

  18. @Ian,

    There is a difference between being an agilist and being agile.  You are clearly a quality-oriented man, and I respect that.  I’m sure that if we were working together, I would value the opportunity to learn from you and be part of the same team.  You have applied your passion to self-improvement and excellence.  Few developers achieve that level of self awareness.  

    On the other hand, there’s Mort.   He doesn’t do those things.  

    So perhaps the statement to add to the manifesto would be "We believe in self-awareness over command and control"

    And in that, you would be very seperate from Mort.

    You are right to inspect the principles to find the place where Mort doesn’t fit.   That said, in any community, the principles are something learned and it requires the community to teach them.  The community strives towards excellence through this mechanism.  Mort is not part of that.

    Mort stands by himself.  Not part of a community.  Mort is paid to be what he is… he is paid to fix things without thinking too much about them.  Mort is what happens when "command and control" structures decided that the organization needs to get things done according to the agile principles, instead of having the developers do it.

    Regardless, the point I’m trying to make, and it is doing me no good to make it because it is wildly unpopular for people to hear, is that Mort exists for economic reasons, and the agile alliance cannot remove the proliferation of bad code through the education of Mort or the improvement of the tools that Mort uses.  

    That is not what made Mort and that is not what will unmake him.  Therefore, it is beyond unfair to blame Microsoft for the existence of Mort or to hold us (or any other software vendor) responsible for not "building the right tool" that will make him go away.

    What I’m sick and tired of, is the statement that Sam made on my blog a few days ago: "Microsoft makes tools for Mort."  Horse hocky.  Microsoft makes tools for the market.  The market employs Mort and they demand tools for their employees, including Mort.  

    If we want to get rid of Mort… forget it.  Ain’t gonna happen.  On the other hand, if we want to constrain the situation that encourages the generation of large volumes of bad code… that’s not hard to imagine at all.  It’s hard to do, but not hard to imagine.  Still working on it.

    And that is the point of my blogs.  Don’t blame Microsoft for Mort.  We didn’t make him.  But we are doing more than most to constrain him.  

  19. I don’t blame Microsoft for supplying Mort with tools. I don’t accuse Microsoft of creating the need that Mort represents, but you did give that need a name. There will always be a place for Morts because there will always be someone who wants a quick and dirty fix on the cheap.

    What I disagreed with is the assertion that Mort can be considered as behaving in an agile way with agile represented by your intepretation of the manifesto.

    I think part of the problem is the emphasis just on tools. Everything possible is done to minimise the need for understanding. Enable people to program without having to learn to program. This removes barriers to entry, but doen’t support a growth path. Not enough is done on the practice side to encourage people to move beyond the tools and understand the practice of software development.

    I would love to see the ratios of developers considered to fit the different personas and how that has changed over time.

  20. @Ian,

    The personas are no longer used.  I made myself familiar with them a while back, but they are vestiges that have long since been discarded as too simplistic to guide thinking about product features.  I’m always a little surprised when they come back up.

    You say that "Everything possible is done to minimize the need for understanding".  Perhaps we have a different definition of "value" but the goal is to deliver business value… and that comes from understanding the business problem.  It does not come from understanding the technology needed to deliver it.  

    No one is building tools to minimize the need to understand the business problem.  Not Microsoft and not anyone else.  I cannot emphasize that enough.  

    The technology should be self-apparent and self-organizing, and if it isn’t, that is OUR fault.  

    Mort is ready to take that self-apparent world and deliver value to the business, because most of the Morts I know (and I know a few) are quite intelligent people who just don’t care about understanding the details of technology, but who care rather passionately about the business problem.

    And in the future, when we succeed in delivering a world where software is free, Mort will deliver solutions quickly that the business finds valuable and which are easy to fix.

    And that is agile because Mort will "satisfy the customer through early and continuous delivery of valuable software."

    That is the first priority.  

  21. I certainly believe in delivering business value. Especially on-going business value.

    However I don’t see a lot of that coming from the software industry. Far too often I see bad practice and short-term fixes that lead to rigid, brittle, difficult to maintain systems.

    From my perspective a major cause of that is a lack of understanding from both business and IT of the consequences of what they are doing and how they do it. Modern development toolsets enable solutions to be developed and deployed quickly. But is developing a bad solution quickly a good idea?

    In a lot of ways I don’t see a huge difference between the functionality being delivered to businesses today through web applications and what was delivered in mainframe apps of twenty years ago. The screens might be prettier but the metaphors haven’t progressed.

    It’s the thinking part of the development life cycle that has been neglected.

  22. Hello Udi,

    Good Question.  I would answer by looking at the more mature industries, where design is a small part of construction and very highly valued, but also very highly leveraged.  

    In other words, folks who need to quickly compose an application aren’t doing design.  They are building with legos.  Their design choices are constrained by the tools on hand, and that is OK.  90% of all commercial buildings are built that way, as are over 95% of all residential buildings.  

    Design, in the sense of the artist or craftsman, which is the state of maturity of our industry today, will gradually diminish in quantity, dramatically increase in quality, garner very high salary, be translatable worldwide, and will become a much more visible differentiator in building strategic solutions for competitive advantage.

Leave a Reply

Your email address will not be published. Required fields are marked *

two × 1 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.