Today, software developers have a slew of alternatives. Many technologies are available, and making the right choice is always a challenge. Azure? WCF/.NET? Web 2.0? … Access? Why choose one architecture rather than another? All too often, I find people wielding the "Golden Hammer" – the tool of greatest familiarity. When you really understand a technology, you can always find an argument to use it. Ultimately, the chances are high that the familiar tool will be the tool of choice.
A simple scenario
In this article, I will describe different styles in a scenario where a user is attempting to generate a report based on two pieces of information, Persons and Matches. The user consults an Excel Spreadsheet that contains values for each Person and for each Match like this:
|Match 1||Match 2||Match 3||Match 4|
A report for each Person with the Matches and the associated scores would look like this:
This report would be customized to insert images, add colors, etc. In addition, this report should be in PDF format.
Let’s now consider different style approaches to the above scenario.
The geek style will most likely entail an Azure, MVC, JSON-enabled application. The developer’s biases will revolve around new technologies and the low cost of deploying this kind of software in the cloud to avoid maintaining infrastructure.
In the end, this is a good choice, and the client will not have to refactor the application for a couple of years. However, not all clients are technology savvy, and they may not want to rely on technologies that require a Geek approach to implement any changes. For a simple application, after all, this may be a little excessive. I call that Programmer’s Golden Plating.
Web 2.0 Style
The Web 2.0 style developer will also propose a recent approach without going too far or deeply into the most recent technologies – maybe just a website using ASP.Net with some Ajax callbacks to make it more responsive, along with some third-party controls to avoid re-inventing the wheel.
There is no problem with this approach (like the last one), except that the client must buy hosting for the ASP.Net website, and must rely on a developer to make changes. Is that really required for the scope of this application? Surely not.
The OLE style is ruled by the "it’s always worked this way" mode of thinking. The developer will propose a client-server application, possibly based on recent technologies such as SQL Server Express and a fat client in .NET. This architecture is simple and straightforward, with almost no infrastructure component.
The OLE approach could work, and the probability of finding resources to maintain those technologies is quite high. However, the client’s actual needs may only include the ability to modify a report or modify some screens. Is a full-fledged application really required for a three tables application?
The MOS style developer (where MOS stand for Microsoft Office Specialist) is an Office power user who knows the ins and outs of development using Office products. This variety of developer may suggest an Access Database, with a form for data entry and a reporting functionality.
In this case, there are no infrastructure components, and the user can modify every bit of information in the database. The user can even go as far as modifying the report or adding a new one. While it’s not comparable to the aforementioned styles, it is a hybrid between the current implementation and the development of a compiled application.
Maybe that is the satisfactory solution to the need expressed by the client.
The value style is an entirely different approach to the problem. It is exactly what it sounds like – a focus on the real value of the application. Sorry people, the software is not the real value here. The value is always what the user can achieve using that software.
So what is the real value in this scenario? It’s to create a printable format of transposed information automatically. All the other styles can achieve that, but value style makes no mention of stability, performance, centralization or technology. So, what is the more straightforward way of delivering the value in this case?
Right now, it’s an excel sheet. We can print Excel sheets. We can transpose information (the paste options are pretty extensive). And we can automate things using macros.
One hour later and the solution is delivered – an Excel workbook with a macro that generates sheets based on a template sheet using the transpose paste option of Excel. After executing the macro, the client only has to use the standard save options of Excel 2013 to save it in PDF format.
Certainly, this is a scenario with an obvious implementation that could be discovered in less than 15 min. I am not saying that any of these technologies are better than the other, and I am definitely not saying that Excel is the solution for everything. The point here is to focus more on the value and less on the implementation. We should always deliver quality software. We should always think about all "-ty". However, we should also think about the real value in what we do.
A simple way of finding value begins with asking a simple question:
"What is the benefit of using software instead of using pen and paper?"