This site is often under construction as it is used to expand my skills by exploring ideas and techniques for .NET, combining ASP.NET, Silverlight applications, web services, and a VB/C# desktop client to access selfsame web services.

Updates and Announcements


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


My name is [removed name] and I am looking to build some technology infrastructure for a hedge fund. The tools will include the typical workflow automation including order management system including execution and allocation, security master, position reconciliation, reporting, etc. I am trying to decide on the technology stack and whether I should build a web based system or a desktop one. All my experience has been in WPF but it seems the world is moving to the web. I feel the benefits of web aren’t that applicable to my use case (see below) and the web has not reached the level of robustness that we see in desktop. But, I am saying all this without years of javascript experience under my belt. Unable to make an objective decision, I thought to look at LinkedIn to see if there are people in this domain who have experience of both desktop and web development and can offer feedback. I found out your profile. Would really appreciate some feedback.

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:

  • 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
  • JavaScript/HTML/CSS as needed to fill out your web stack
As for third-party tools
  • DevExpress or Telerik for server-side Excel generation
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.


PS, Feel free to reach out if you want to chat.


NuGet Publications

I recently published several NuGet libraries, partially for the experience, since using NuGet for sharing code within an organization seems an easy and worthwhile solution.