On the Big Ball of Mud, a reading on the paper by Foote and Yodder

I found the Foote and Yodder paper "Big Ball of Mud" most interesting. I have spent much of my working career firstly, testing said balls of mud, then managing the building and deployment of the mud. I'm now a product manager, making sure we no longer build mud :)

For reasons of financial necessity or just disorganisation a lot of development teams have short sighted goals, where any kind of working delivery is viewed as a far better outcome than taking longer to make a more reliable or easier to maintain solution. By taking this approach, these short-sighted teams will build up technical debt. That is, they will get their working delivery on a high-interest lease program, with a large payment due in the future as their system is difficult to  expand and upgrade.

Think of an ERP system. In one of our previous modules, we were told a number of large investors used a company announcing the roll out of an ERP system as a merger and acquisition strategy. These investors considered ERP systems so complex & expensive a number of companies investing into getting them in place will run into problems and cripple the company. You often see and hear of companies having these systems in place, and they get someone to customise them, to suit their practices & desires. This makes this easier day to day, which is good. On the flip side this is a fast track to ball of mudland!! I managed an instance of SalesForce [a CRM system] for a large finance company. Their SalesForce instance was *very* heavily customised. What this meant was that when SalesForce did their system wide upgrades 3 times a year our system fell apart, and once took three weeks to fix. When I left that company SalesForce were about to retire two features we were heavily dependent on. We had never taken the time to upgrade them [3 years after they first said they would replace them]. Management simply put the update on the long finger, and left them alone as we had spent so much time and money customising the system. That it was deemed too expensive, it did not add any value. So then, down the road, they were faced with a major upgrade project, with a gun to their heads, and half the time and necessary resources available. Insert more mud here!!

I do like the focus, so far on this course, in thinking about how a product manager would think. As a product manager you need to think about getting your "thing" out the door. But you also must have an eye on medium and longer term goals. So there is very little benefit in getting a version 1 out there, if its unstable or impossible to maintain, as by the time you deliver it, plans are well underway to your next set of enhancements. Consider this article, from an industry blog I often read. This article describes how you break down complex items into easy to digest user stories which your development teams can then consume. They can build their solutions accordingly. But it is very much implied [and I would reinforce in person], that in the example on that website example, I want the ability to later add currencies, change prices etc. You build your system with that in mind from day one, it takes longer out the door, yes - but later enhancements are easy [as is testing and eventual refactor & redesign]