Hamish Rickerby

Technology Consultant & iOS Developer based in Sydney, Australia

Coding vs Configuration - the Vendors Are Missing the Point, and the Customers Aren’t Helping

| Comments

Large software vendors do (often in the long term) listen and act on what their customers say they want. However, implementations are still missing the point. What customers say they want and what they actually want can be very different things.

Historically people (like me) in enterprises have harped on to vendors for years about how we want their large enterprise applications to be more configuration driven rather than coding driven. The actual purpose behind this was about time to market, resource availability with the necessary skill sets required to maintain and alter the application, effort around testing and deployment, and certainty about the validity of the syntax and sensibility of the customisation. Vendors have responded by closing the code base, but offering more complex configuration environments - which is exactly what we have asked for (see next paragraph about how we have asked for the changes). However, what they have provided doesn’t meet the actual business goals of the request. For example, I’ve been recently looking at some Product Configuration software that has a guided Java coding environment for rules definition. This doesn’t actually make the implementation simpler. It means that your (previously) relatively unskilled (and that’s flame bait if ever I’ve seen it) configuration staff have to significantly increase their skills to match those of java developers. Its called “configuration” because its done in a “configuration” tool. The configuration tool is as much a config tool as Eclipse is (which has code completion BTW, is equally applicable for the task, probably nicer to use and definitely cheaper). What it’s done is moved the effort from the development staff, to the configuration staff. Assuming staff are happy with what they do, developers are unlikely to want to join a “configuration” team, and configurators are unlikely to want to gain development skills. One may also argue that your testing and deployment efforts are more difficult, because the coding that was done by people who know how to code, is now done by people who don’t know how to code - this in my mind introduces more risk. You also don’t know which parts of the application are affected by this complex configuration activity, and this may drive for more rather than less regression testing.

I’ve also been reading recently about user stories, which are something I’ve never professionally come across. I’ve been working for my entire professional career on waterfall based implementation projects, with requirements and scope specified in documentation like traditional UML use cases, interaction/sequence diagrams, and IEEE 830 style requirements. I wonder if the large enterprise is its own worst enemy when it comes to vendor software direction and influence. We are always writing (and that’s the first mistake) very specific (and that’s the second mistake) requirements for vendors to implement, and influencing them through RFIs and RFPs which contain hundreds or thousands of these requirements. Maybe if the interaction was more conversation and (business) outcome based we’d actually get what we wanted, instead of getting what we write down - which is always going to be flawed (inaccurate, incomplete, technology based rather than business value based, and driving misunderstandings between reader and writer). Conversations about outcomes are the way to get around the limitations of written software system specifications.

What we actually want and what we get are often different things. I’m beginning to understand that outcome driven conversations between parties playing their specific roles are the way to go. In a supplier-customer relationship, the customer should tell the supplier what they want to achieve (in a business context), perhaps explaining why the current implementation does not meet their needs. The suppliers role is to understand the customers issues and the drivers behind why those issues are actually issues, and then propose ways those issues could be resolved. Often it may be a process or simple usability issue, sometimes there are fundamental issues with the implementation that require longer term efforts to fix. Regardless, the vendors know their software and the capabilities it possesses and the customers know their business drivers and understand how they are using the software. Each party should focus on playing their part in the relationship and achieving their eventual outcome (customer = achieving the business value and business purpose they want, and vendor = getting a satisfied customer, which hopefully translates into a big purchase order for them).