Software Engineers and Obsolescence
An article Software engineers will be obsolete by 2060
, prompted a response from me, citing an interesting article from The Economist titled Automation on Automation Angst
, that looks at several publications that look at the historical effects of automation, and although there is always fear of being replaced, ultimately more jobs are created than destroyed. Software engineers disappear? So what! There will be other jobs, with different titles, and in the interim, the more people use tech, the more there will be a need for software engineers.
Response to Request for Opinion
Some quick thoughts on architectural constraints. At best, this software will have 100-200 users. Not more than that. The software will not have to handle more than a thousand transactions a day. There will be realtime updates via Bloomberg data libraries etc so whichever technology stack we use needs to be robust. There isn’t any super low latency requirements like high frequency trading but the software should feel responsive like a desktop application does.
Would love to hear your thoughts. Thanks in advance.
It is not either, and it is likely both. Hypothetically, you would like to make an infrastructure that is platform-independent, e.g., service-based, so that you can reach your data and processes regardless if it is web-based, desktop, or server-side. As for the world going web, I have seen a big increase in WPF job openings, particularly in the trading sphere.
As for specifics, web is lightweight, desktop is heavyweight. The easiest rule of thumb, and by no means comprehensive, is that if you need to manipulate and display large amounts of data, need access to a desktop notification system, need live updating, and need Excel/Bloomberg integration, you would choose desktop. For lightweight apps, that might have less demanding needs, you could use web, and if there are workflows and processing required for reporting and order flow, you might build a set of services and processes that can be triggered from the lightweight front-end to a more serious server-based system.
You might want to keep your technology stack small, since your needs are small, so go with Microsoft, unless your skill sets are elsewhere:
As for third-party tools
- SQL Server, with SQL and T-SQL
- WCF, et al., for services
- WPF desktop, using MVVM pattern and/or Prism
- ASP.NET MVC for web, with Entity Framework
- SSRS for basic reporting
- VSTO for Excel add-in integration
- C# as the common language for desktop, web, and server
A personal dislike is SSIS. Instead, code a system that can handle FTP, file transfers, and ETL; it is simple, and if architected well, should be able to grow as your needs grow.
- DevExpress or Telerik for server-side Excel generation
PS, Feel free to reach out if you want to chat.
published several NuGet libraries
, partially for the experience, since using NuGet for sharing code within an organization seems an easy and worthwhile solution.
Waiting for Deployment
I read an article this morning about the #NoEstimates movement,
Estimates? We Don’t Need No Stinking Estimates!
, which reminded of an author I have always liked, Samuel Becket. He has a very dark sense of humor, technically absurdist, and his characters’ statement are not literal. Anyway, it made me think of this, borrowing from Beckett:
Ever estimated. Ever failed. No matter. Estimate again. Fail again. Fail better.
Interesting new links
Some useful new links for mobile development from Google, and for WPF from Christian Moser: