For a long time it has bothered me that inferior products manage to top the charts of their prospective fields. Maybe this was because the marketing department was better at the company with the inferior product, or maybe it was that the marketing team sucked at the company that chose to invest in engineering.
Today I was reminded of what can go wrong when the engineering arm of a company invests too heavily in that field without looking at the overall picture of what is required for a good product roll-out.
A company was offering character recognition software for automating the entry of invoices into a system. The premise is very simple, take some text on a scanned document and enter it into some fields that can then be exported to the customers database. Everything about this product ticked all of the boxes except for one thing, the interface. For some reason, someone within the IT department managed to convince everyone else that silverlight was the way to go. There is nothing wrong with silverlight, don't get me wrong, provided silverlight is the best option to go with and no other tool can offer the functionality required. Otherwise you are locking yourself into that particular vendor and restricting the platforms you can actually run the application on. If the customer wants a web based system they can also view on their phone / tablet, silverlight really isn't going to do you any favours.
Functionality vs Complexity
So what drove this company to go with silverlight? Maybe they thought it was right for their customer base at the time, or maybe the devs wanted something new to play with and thought they could bolster their CV with a bit of silverlight on it. This is where the complexity comes in. If you have a tool that you think aids development, ask yourself this question. If you're going to be employing someone new into your company, does having experience in that product become a prerequisite to the job? If the answer to that question is yes, then the tool isn't actually helpful. Take resharper and SSMS Tools for instance. Both great plugins for visual studio / SQL Server Management Studio. However you wouldn't state that a developer had to have experience in using them before joining your team. However if your company has decided to use an ORM layer like nHibernate or Entity framework, where do you go from there? All you are doing is diluting the pool of applicants you might be able to source for the job.
Bad Product Release
On the other hand, there are times when a bad product release can undo all of the good work of the engineering team. Not setting sensible values for defaults leaves people thinking your product is inferior. 80% of your user base is not going to take the time to wade through pages of options and configuration. They are trusting that the Release team chose a sensible set of values that cater for the majority of their customers.
So what is the right level/trade off for all of this? I honestly don't know, it depends on your user base and what they want. The only way you're going to find this out is through market research. So the emphasis is back on the marketing team again! I hope that one day the user base will improve so they can make a choice based on engineering superiority rather than aesthetics. If that happens, companies like Saab will still be in business.
