Archive

The Dulin Report

Browsable archive from the WordPress export.

Results (86)

Strategic activity mapping for software architects May 25, 2025 On the role of Distinguished Engineer and CTO Mindset Apr 27, 2025 The future is bright Mar 30, 2025 2024 Reflections Dec 31, 2024 My giant follows me wherever I go Sep 20, 2024 The day I became an architect Sep 11, 2024 Are developer jobs truly in decline? Jun 29, 2024 Leadership is About "We," Not "I" Jun 9, 2024 Form follows fiasco Mar 31, 2024 Software Engineering is here to stay Mar 3, 2024 Some thoughts on recent RTO announcements Jun 22, 2023 On Amazon Prime Video’s move to a monolith May 14, 2023 One size does not fit all: neither cloud nor on-prem Apr 10, 2023 Some thoughts on the latest LastPass fiasco Mar 5, 2023 Comparing AWS SQS, SNS, and Kinesis: A Technical Breakdown for Enterprise Developers Feb 11, 2023 Working from home works as well as any distributed team Nov 25, 2022 Why you should question the “database per service” pattern Oct 5, 2022 Stop Shakespearizing Sep 16, 2022 Why don’t they tell you that in the instructions? Aug 31, 2022 Monolithic repository vs a monolith Aug 23, 2022 Automation and coding tools for pet projects on the Apple hardware May 28, 2022 There is no such thing as one grand unified full-stack programming language May 27, 2022 Most terrifying professional artifact May 14, 2022 If you haven’t done it already, get yourself a Raspberry Pi and install Linux on it May 9, 2022 Good idea fairy strikes when you least expect it May 2, 2022 Kitchen table conversations Nov 7, 2021 Application developers like to think their app is the only one Apr 5, 2021 A year of COVID taught us all how to work remotely Feb 10, 2021 What programming language to use for a brand new project? Feb 18, 2020 The religion of JavaScript Nov 26, 2018 Teleportation can corrupt your data Sep 29, 2018 Let’s talk cloud neutrality Sep 17, 2018 What does a Chief Software Architect do? Jun 23, 2018 Nobody wants your app Aug 2, 2017 TypeScript starts where JavaScript leaves off Aug 2, 2017 Singletons in TypeScript Jul 16, 2017 Emails, politics, and common sense Jan 14, 2017 Online grocers have an additional burden to be reliable Jan 5, 2017 Collaborative work in the cloud: what I learned teaching my daughter how to code Dec 10, 2016 Apple’s recent announcements have been underwhelming Oct 29, 2016 What I learned from using Amazon Alexa for a month Sep 7, 2016 Why I switched to Android and Google Project Fi and why should you Aug 28, 2016 Amazon Alexa is eating the retailers alive Jun 22, 2016 In search for the mythical neutrality among top-tier public cloud providers Jun 18, 2016 In Support Of Gary Johnson Jun 13, 2016 Files and folders: apps vs documents May 26, 2016 What can we learn from the last week's salesforce.com outage ? May 15, 2016 Why it makes perfect sense for Dropbox to leave AWS May 7, 2016 JEE in the cloud era: building application servers Apr 22, 2016 Let's stop letting tools get in the way of results Apr 10, 2016 JavaScript as the language of the cloud Feb 20, 2016 LinkedIn needs a reset Feb 13, 2016 In memory of Ed Yourdon Jan 23, 2016 Our civilization has a single point of failure Dec 16, 2015 IT departments must transform in the face of the cloud revolution Nov 9, 2015 I Stand With Ahmed Sep 19, 2015 Setting Up Cross-Region Replication of AWS RDS for PostgreSQL Sep 12, 2015 Top Ten Differences Between ActiveMQ and Amazon SQS Sep 5, 2015 We Live in a Mobile Device Notification Hell Aug 22, 2015 What Every College Computer Science Freshman Should Know Aug 14, 2015 On Maintaining Personal Brand as a Software Engineer Aug 2, 2015 The Three Myths About JavaScript Simplicity Jul 10, 2015 Book Review: "Shop Class As Soulcraft" By Matthew B. Crawford Jul 5, 2015 Attracting STEM Graduates to Traditional Enterprise IT Jul 4, 2015 Your IT Department's Kodak Moment Jun 17, 2015 The longer the chain of responsibility the less likely there is anyone in the hierarchy who can actually accept it Jun 7, 2015 Big Data is not all about Hadoop May 30, 2015 Smart IT Departments Own Their Business API and Take Ownership of Data Governance May 13, 2015 The Clarkson School Class of 2015 Commencement speech May 5, 2015 My Brief Affair With Android Apr 25, 2015 Exploration of the Software Engineering as a Profession Apr 8, 2015 What can Evernote Teach Us About Enterprise App Architecture Apr 2, 2015 Microsoft and Apple Have Everything to Lose if Chromebooks Succeed Mar 31, 2015 Do not apply data science methods without understanding them Mar 25, 2015 On apprenticeship Feb 13, 2015 On Managing Stress, Multitasking and Other New Year's Resolutions Jan 1, 2015 Why I am Tempted to Replace Cassandra With DynamoDB Nov 13, 2014 Software Engineering and Domain Area Expertise Nov 7, 2014 Docker can fundamentally change how you think of server deployments Aug 26, 2014 Wall St. wakes up to underinvestment in OMS Aug 21, 2014 Software Engineers Are Not Doctors Aug 3, 2014 Thanking MIT Scratch Sep 14, 2013 Have computers become too complicated for teaching ? Jan 1, 2013 Thoughts on Wall Street Technology Aug 11, 2012 Scripting News: After X years programming Jun 5, 2012 Java, Linux and UNIX: How much things have progressed Dec 7, 2010

Thoughts on Wall Street Technology

August 11, 2012

Last week I went on vacation and missed the news that a software error at a major market maker caused almost half a billion dollar worth of trading errors, which required a rescue by a group of investors. Mainstream media is quick to point out that high frequency trading should be more regulated, but as a software engineer I find that this has more to do with process and management than with the trading technology or software itself.

As I've been gathering my thoughts on this topic for the past few days I came across an article by Robert Dewar, one of my most respected professors at NYU Courant Institute where I did my masters. Dr. Dewar's main point is that safe and trustworthy software is possible if the company has proper processes and a proper culture in place.

Wall St. companies could learn from this. Companies so dependent on technology should not be run by traders -- they should be run by technologists. From CEO level down to the humblest engineers, these companies must be staffed with technically minded people who have the right training, the right attitude, and the right thought processes to build reliable and trust worthy software (but such developers are never on the market, so this creates a conundrum, right?)

How many Wall Street job openings have you seen that proclaim "fast pace" as one of the exciting aspects of the job ? To be clear, when a recruiter contacts me about such a job opening I immediately brush it off. It is this "fast pace" of development, this requirement that something requested this morning must be in production by midnight today, is what time and time again gets Wall St. technology into a pickle. As one of the commenter's on Dewar's article said, senior management and sales should not under any circumstances be allowed to rush software development process. Human mind is simply not capable of accelerating its cognitive processes, and therefore forcing developers to build software faster is counterproductive.

Following this line of reasoning that developers are humanly unable to think faster than they do, production support and active development must be thought of as two distinct areas that should be staffed by different people. Under no circumstances should engineers be forced into a situation where they are expected to deliver working code -- while also responding to phone calls from traders and customers every fifteen minutes. Bug fixes are too a distinct activity from software development.

Dr. Dewar concludes his article:
High-frequency automated trading is not avionics flight control, but the aviation industry has demonstrated that safe, reliable real-time software is possible, practical, and necessary. It requires appropriate development technology and processes as well as a culture that thinks in terms of safety (or reliability) first. That is the real lesson to be learned from last week's incident. It doesn't come for free, but it certainly costs less than $440M.

NASA's overall budget is about $10 billion per year. Wall Street technology spending is about $40 billion, depending on who you talk to. NASA is able to find developers and subcontractors who can program a robot from 250 million miles apart, or safely launch humans into orbit. Wall Street could benefit from recruiting the same kind of engineers and managers and offering them meaningful career paths.