Quantcast
Channel: MSDN Blogs
Viewing all articles
Browse latest Browse all 35736

The Value Style

$
0
0

Today, there are many alternatives when developing software. Many technologies are available and doing the right choice is always a challenge. Azure? WCF/.NET? Web 2.0? … Access? Why choosing an architecture more than another? I saw many times the Golden Hammer. When you really understand a technology,  you will always found an argument to use it. So at the end, there are good chances that you will use it.

A simple scenario

In this article I will describe different styles, in a scenario where a user is asking to simply generate a report based on two types of information, Persons and Matches. The client use an Excel Spreadsheet that contains values for each Person and for each Match like this:

 Match 1Match 1Match 1Match 1
Person 14385
Person 21742
Person 391058
Person 468107

And he want to generate a report for each Person , with the Matches and the related score like this:

Person 1
Match 14
Match 23
Match 38
Match 45

This report should be customized to insert images, add colors etc. Also, this report should be in PDF format.

Styles

Let's think with different styles or with different point of view.

Geek Style

The geek style is surely the one that will propose an Azure, MVC, JSON enabled application. His arguments will turn around new technologies and the low cost of deploying this kind of software in the cloud, to avoid maintaining infrastructure.

At the end, this is a good choice… and the client will not have to write the application for a couple of years. But in the context of a client that is not technology-aware, he may not want to rely on technologies that require a Geek Style guy to do some changes. And maybe it’s a little excessive for this kind of application? I am calling that Programmer’s Golden Plating.

Web 2.0 Style

The Web 2.0 style guy will propose a recent approach without going to far in recent technologies. Maybe a website using ASP.Net with some Ajax callbacks to make it more responsive, and 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 should buy hosting for ASP.Net website, and should rely on a developer to make changes. Is that really required for the scope of the application? Surely not.

OLE Style

The OLE style is ruled by the “it always worked when doing it that way” thinking. He will propose a client server application maybe based on more recent technologies such as SQL Server Express and a fat client in .NET. Simple, straightforward, almost no infrastructure component.

This could work, and the probability of finding resources to maintain those technologies is quite high. Going back to the need, the client may want to modify a report or modify some screens… Is a full fledged application really required for a 3 tables application?

MOS Style

The MOS style (where MOS stand for Microsoft Office Specialist) is an Office power user that know how to develop using Office products. This kind of profile may propose an Access Database, with a form for data entry and a report.

In this case, there is not infrastructure components, the user can modify each and every information in the database. He can even go as far as modifying the report or adding a new one. Even if it’s not comparable to the other style, it is an hybrid between the current implementation and the development of a compiled application.

Maybe that is the solution. Maybe we finally found the solution to the need expressed by the client.

Value Style

The value style is a different approach of the problem. It as simple as focusing on the real value. Sorry guys and gals, the software is not the real value, the value is 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 other style can achieve that, but in the value requirements there is 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 after, the solution was 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 just have to use the standard save options of Excel 2013 to save it in PDF format.

Final Note

For sure this is a simple scenario with an obvious implementation that could be found in less than 15 min (actually it was found in less than 15 min). I am not saying that any of those technologies are better than the other, and I am surely 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 think about all “ty”, but we should also think about the real value.

Here is a simple way of finding it, just ask you a simple question:

What is the benefit of using a software instead of using a pen and a paper?

-f.


Viewing all articles
Browse latest Browse all 35736

Trending Articles