A few days ago, the chief architect of the company I work for sent me an email, with the link of an article and the following comment : "I think he's not wrong". He was referring to an article written by a MVP, posted on csharpcorner. To sum up, he explains that the software development is getting more and more difficult with Microsoft (it's a very short summary, I advise you to read this article if you want to go through the one you are currently reading).
To be honest, I never developed with Visual Basic so I don't really know what he is talking about when he refers to the VBX for example, however I used many RAD (Rapid Application Development) solutions from Microsoft, like the drag'n'drop in ASP.NET, or the Entity Framework EDMX that he seems to regret, but I far prefer the current solutions. In my opinion, the RAD solutions always made people lose much more time than saving some, as they were very effective only in a limited perimeter, in a few identified cases, and were complex to adapt to specific needs. The drag'n'drop of components or data sources was really effective only for basic applications, for reading and writing data in grids.
One of the main ideas of this article is that the software development is more and more difficult using the Microsoft tools, which I think is an unfair reproach. The first reason is that I remember some projects in ASP.NET in which the URL rewriting could mobilized a whole team, sometimes for weeks. In these projects, we also had to handle a lot of technical issues without any functional value that required a constant vigilance, as for example the aspx postbacks or the viewstates’ size. The MVC was a true revolution, as it was perfectly adapted to the Web development, allowing the developers to focus only on their core job, without being bothered by diverse technical complications without any functional added values. ASP.NET Core continued in that direction, redesigning some basic areas of the .NET Framework and releasing a lot of useful technical features or services, as the dependency injection service which is a good example of the Microsoft’s performance.
Certainly, the software are harder to develop today than 20 years ago, but the context has radically changed. Is Microsoft responsible for the fact that most of the web connections are made from smartphones which all have their own characteristics? Is Microsoft responsible for the existence of more and more hardware devices, potentially increasing projects’ complexity? Besides, if Microsoft was going the wrong way or would be incompetent, a miracle solution would already have been created, but it is not the case. I agree with the article’s author when he affirms that Microsoft is progressively getting away from the RAD solutions since a few years, but is it really a mistake? Personally, I don’t think so. The RAD tools always presented their constraints and limits, while the current solutions allow you to build exactly what you need. He has some regrets about the EDMX, while the Entity Framework Core model builder is so powerful. I admit that it does not contain functionalities to create a schema and design a data model using only some left and right mouse clicks, but it is modelled on the Microsoft development tools in this day and age: the tool allows you to do exactly what you need, on condition of mastering it. To obtain a schema of your data model, other tools will be needed, but it is not the purpose of the EF Core model builder, and I personally think that it is for the best. With the software products that Microsoft proposes today, you certainly start from a blank page, but you can go wherever you want to go, following the way you choose and prefer.
The author concludes his article criticizing the Microsoft documentation, even though the last documentations are detailed, well organized and open-source. Considering that sharing content and knowledge is one main advantage of our time, if you notice a lack of information about something, don’t you think it would be more appropriate to complete the documentation instead of grumbling? It would surely be more useful.
I share with the author a dream of the software development’s future, modelized by a "perfect tool" which would allow with a few mouse clicks to build a complex and specific software, compatible with iphone / google chrome/ ipad / ipod / freebox / windows tablet / android tablet / firefox / connected watches as well as connected clothes. In the case I can’t have this, then I’ll go for powerful tools allowing me to develop exactly what I want, freeing me from useless issues, so that I can be only focused on my core job. Even if these tools require some time to learn how to use them properly, I think it is a good start.
Getting back to my "perfect tool", I admit that I do not have a great deal of hope concerning its feasibility. First, I think that the hardware devices are only at the beginning of their evolution, development and diversification. Second, as Humans, the tools which do everything, and additionally do it fast, never do it well.
PS: this article was originaly published on my personal blog.
Top comments (2)
Liked your post! I agree that RAD is difficult to get right. That's why there are separate design tools and developer tools. Getting RAD right (and accepted by more savvy devs) could be considered the holy grail to productivity.
Just scanning back through posts I missed, and I like your response to the article. I wrote (and am still shackled with) many apps in ASP.NET WebForms. Those kinds of applications were the bread and butter of consultants, because they are really fast to get going. But they are a nightmare to maintain as time goes on. You have to learn a litany of intimate details of these frameworks to go beyond the simple. The framework knowledge dependency (i.e. Page Life Cycle, ViewState, rendering details of controls for styling purposes) becomes ever-increasing technical debt that has to be paid on every new feature. You might buy 3rd party tools in attempt to shield yourself from this. But this ends up being only a stalling tactic, and knowledge dependency simply shifts to those tools. This is why you see dev jobs that have a checklist of specific frameworks/products you must know to even bother to apply. Consultants often do not see this downside, because the app has long been handed off by then. And the really sad bit is that the deep framework knowledge required to keep these apps alive is not portable. It is too localized to be of use anywhere else. I think this is the essence of what the author is really lamenting since these are in decline. But I say good riddance!