Recently, I overheard a very curious statement. This statement was made in regards to Visual Studio versions, and it was a discussion that many developers use Visual Studio 2012 or 2013. The quote went something like this:
… those people likely have a shitty job; they are maintaining legacy code of some kind. There are still some people who have to use Visual Studio 2010. Feel bad for those people, they are probably dealing with real, serious, every-day frustrations beyond just code. Like their company is run by cheap bastards who won’t let them upgrade to newer tech
The perspective being shared here is that, essentially, if somebody is not using the latest-and-greatest version of an IDE, they must work for a shitty company and shitty people and everybody else should feel bad for them.
Notable, however- was that there was
As with any version of a program, you shouldn’t be awed by the marketing rhinestones.
- Does this new version have features or capabilities that make my work easier?
- Does this new version have shortcomings that make my work harder?
- Is the net affect of the two listed considerations worth the cost of switching?
This applies to any software version. Merely presuming that the latest version is going to be objectively better for every task than the previous version is merely ignorance. In the case of Visual Studio 2015, it works fine for my own projects, but I’ve found it simply doesn’t work for work projects. And even in the former case, it’s a situation of “Well, I may as well use it while I can” rather than “oh wow I am so happy to use this latest and greatest version because of X,Y, and Z!”. It doesn’t work for Work projects not because the work projects use ancient code that relies on, say, .NET 1.1 or something. The main issue is that we simply don’t gain anything by using Visual Studio 2015- so there is no point in doing so, since switching to VS2015 would represent a non-zero effort by every developer.
it is frustrating trying to relate to modern software development. I’m 28 and I already feel that I’ve lost touch because I’m no longer interested in using the latest whiz-bang feature Microsoft has put out. Aside from the fact that they cannot seem to make up their damned minds about WHAT they are going to support and for how long, Each new technology is heralded as completely changing how we will develop applications but realistically it just means you are making all the same applications, you are just doing it differently. Or, depending on the tech, it might simply not make sense for all application types. It would be foolish to create a game using WPF, for example. In WPF’s case, it replaced Windows Forms. it is very strange to hear developers talk about Windows Forms as if it is ancient history, and reflect on how they are so glad they no longer have to deal with it. Personally, I’m fine with Windows Forms, and it is quite a different scenario from my situation with VB6. With VB6, I stuck with it because I was ignorant of new alternatives. With WPF, I’ve used it and it’s nice, but it has enough of it’s own idiosyncrasies to make me question any developer who considers it objectively superior. It avoids a few issues WinForms has by design (the DPI consideration for Windows Forms, where it saves design time DPI settings, is one such instance). The main appeal of WPF seems to be that it helps you write less C#/VB.NET etc code. And that is true- you will have less code-behind if you do it properly. But you’ll just have a bunch of weird XAML instead, and Instead of writing code to load and display Customers, you’ll be writing the same amount of code, but you’ll be writing it in the implementation of new classes and new IValueConverter implementations to allow XAML to understand your data in the context of bindings.
Is this bad? No, not at all. The issue, from where I’m standing, is that it really only works best if you are able to design the database and the software simultaneously. You aren’t going to be able to directly use XAML on a ISAM database converted directly to Tables without a rather significant code-behind to construct a reasonable representation of instances of your data “objects” based on that data.
Another- arguably more onerous- issue is that writing against WPF forces your software to run on Windows. With Windows Forms, it is possible to run your software on other platforms using technology such as Mono, but WPF relies specifically on Windows-only technologies such as DirectX which simply are not available on those other platform. The main issue being that you simply cannot really re-use what you wrote in WPF for any sort of cross-platform application, as it is coupled very strongly with WPF.
Realistically, moving to a new technology- Windows Forms to WPF, WPF to- whatever-the-hell Microsoft wants us to use for Windows 10, etc. comes with a significant oppurtunity cost. Additionally, the real issue is that in order to “do it correctly” you tend to need to completely obliterate what has already been built. This introduces significant problems. If you have a customer that is using the old database and has created hundreds of thousands of invoices for an equally large number of customers, with massive gobs of data that they want to keep, you aren’t going to be able to sell them your rewritten product if it means they will have to rekey all of that information. it doesn’t matter what features the software has at that point, because customers simply aren’t going to spend the time to retrain their employees, rekey all the data into your new system, and pay you for the chance to do so. They will continue to use the existing, functional system. This puts the onus on you- the developer- to be able to bring that old data into the new system in at least a semi-automatic way, which means that, at least on some level, the data will need to be compatible. Just having that necessity limits your ability to redesign how things are done, since you are effectively forced to continue to do them the same way.
Fundamentally, making that sort of switch only makes sense for designing a new product, which you will need to sell. If you have customers using your existing software, you may very well *drive them away* just by suggesting that you’ve moved to a new system- they’ll find another software package that works like the one you previously provided and supported. Only technical sycophants are wowed and awed when you say “it uses the latest and greatest technology” because everybody else recognizes that for the marketing garbage that it is. A Piece of software being written in WPF doesn’t magically make it a “better product” than a similar program written against Windows Forms, and it sure as hell doesn’t mean that the WPF program wins any points for simply being newer. If a product doesn’t meet a need that another product does, it doesn’t matter if the former is made out of cyborg amazo quantum computing library deluxe edition- because they don’t need that.
A significant issue with switching is that there is a huge cost involved, and in the long run there tends to be very little benefit. Switching to WPF, for example, for a project that contains decades of effort, is not an undertaking that can be done over a weekend. it requires a significant amount of effort, and all of that effort is being put towards something that simply isn’t going to provide any revenue for years. And when it does- it will be providing the exact same amount of revenue as the current product. meanwhile, that current product no longer receives enhancements and stagnates, and all your customers move to something else, because those other companies have continued to improve their product while you were screwing around with IValueConverter implementations.
And then, when you’re done- you’re just in time to move the product to some new whizbang UI Framework that all the Microsoft sychophants swear is the second coming of Christ in framework form.
It’s actually somewhat interesting to consider that as time has gone forward, even the simplest applications have gotten more and more complicated, and then we get frameworks and other garbage to wrap around that complexity, but we never think about ways to actually reduce that complexity- instead we merely try to hide it behind more and more abstractions, so now you’re building software by stacking metaphors, not dealing with computer code or dealing with computer science concepts or algorithms. You’re stapling a few ready made components into a DataBinding, and maybe writing a bit of glue code to put it all together, and calling yourself a software developer while patting yourself on the back with some sort of weird chimney brush which has no place in this overextended simile.
Have something to say about this post? Comment!