I found all the themes interesting, but "the rigor has to go somewhere" and "the enterprise reality check" resonated.
I was thinking about how my build of software has changed in the past 25 years, and while it feels there's only been small shifts with a great increase in my general grumpiness at stack complexity, the reality is before AI there had been a huge shift in my day to day focus.
When I started out, writing and reviewing code with a focus on managing memory, performance optimisation, tackling crossplatform compatibility were significant chunks of each day. If you didn't do those things, it was unlikely you would be able to sell in the market, because your competitors were faster or better. Then computers got faster, you needed to think about those things less, and you could instead afford focus more on features and getting to market faster.
Those were distant concerns for most of the things I was working on around 2020. The concerns where instead overall system design, distributed systems concerns, and business processes. If you didn't do those things, your product couldn't compete with all those other ones that did those things well (i.e. multi user systems, scaling to thousands of concurrent users etc etc)
If the AI trajectory continues, code as we know it today will become like memory management or hand rolled assembly from the 1990's, just not something you think about anywhere near as much (right up until the point it becomes a problem). You just couldn't afford not to. The focus and rigor will be in how well have we captured and delivered on the business requirements, how well are we responding to changing requirements, how well are we integrating with other systems. There will be some people who will need work on the low level things things, but the majority of of the sector will be working on these bigger picture problems.
Yes, it will create big balls of spaghetti code, unmaintainable monorepos, and everything today we consider bad, messy and wrong. But when the cost of regenerating said code is drastically reduced, you get to focus instead really close to delivering on user requirements. The focus and rigor will shift to verification, i.e. making sure what we're selling does what it's supposed to. Which If we are honest with ourselves that is exactly what we've been trying to do forever, but we just couldn't afford to do it as well as we would have liked. And honestly it was because building things was more fun and more necessary than testing things. That started to shift 15 years ago, and really shift 5 years ago, and now I think its' about to shift even more.
One could argue much of this doesn't fit under the purview of software engineering, but I think it does. For me, software engineering was the process of capturing value and knowledge in a system that could run on a computer, that we did it using coding, and that many things required highly specialised skills was an implementation detail. It will shift in a way that building architecture did - moving away from the raw technical ability to draft plans, and instead be able to understand a customers requirements, understand the legislation that the buildings exist in, and be able to oversee the project to see it completed that it fits all those things.
All true, but also depends on jurisdiction the product is operating in
For example, in Australia any consumer has rights around products and services they purchased regardless of the terms agreed to during sale. If a business offered 99% uptime in their marketing, then they are required to provide that or, something equivalent, or a refund, even if it was never mentioned or some lower number was mentioned in the terms and conditions.
Enforcing that however, particularly with companies that are renowned for having no human staff, is tricky.
So yes, definitely agree - builders have to be aware of their dependencies and work with the realities of what they provide, not the theoretical
I’m confused - is it the actual source code, or minified/bundled code? I don’t think those two are the same thing - unless of course you write your code minified. That would be really impressive.
One of the things I miss most about the Amiga workbench is variable size icons.
I love them, and miss them
That giant battletech icon before you play that fantastic turn based hexagonal game, or the Amos basic icon, there was just so much opportunity for fun.
Ever since then I occasionally try and make it happen on vanilla OS’s, without success.
Them I just realised I’ve been a dev forever, and various desktop environments on Linux have been open forever, it might be time for me to try one last time. It may never take off, but I would love to see it :D
Thank you for writing and sharing that. It's one of the simplest and sane explanations I've seen. How did discussions go with accountants separating the debits/credits into being a presentation issue?
Well, they didn’t like it! :) I considered just providing views onto the tables that would present the data in the way that made the accountants happy. But in the end we just ended up changing to using separate debit/credit columns. They managed to talk me around somehow, but I don’t remember the details any more. I think this was the relevant issue:
Accounts (in the accounting sense) are unitless, and refer to whatever meaning we ascribe to them, so we can transfer value from $ to shares, or USD to GBP or whatever.
Lalit describes this I think really well in his article
I guess it depends on the complexity of ones personal finances? The author had multiple currencies, investments, and who knows what else.
I ran a small business for a while, and I would draw a parallel to that. Once a family's finances hits the complexities of a small business, multiple assets, loans, cars, long term savings, investments, I'd say the granularity is worth it. I would certainly like to try it out.
I tick all the boxes you listed after having worked in a handful of different countries, but personally I don't really see the value add. My bank shows an overview in my main currency of choice and so do brokerage accounts. Perhaps to turn the question around, what value do you get out of it for personal finances? I wouldn't really compare to a business too closely since understanding all of your input costs down to a fine level is much more important there, at least in my opinion. The price of flour doesn't matter too much to the cent when you buy a bag every now and then, but it matters a lot when you're buying in tons.
I used to use an application in France which automatically sorted all my expenses - it sadly doesn't work as well anymore.
I have to say seeing some macro-budget category summed on a year and seeing how much of my money they consume was quite useful just to recalibrate. It wasn't life changing but it triggered things like: am I really ok spending that much on restaurants?
I must have read half a dozen intro-to-accounting books, and it never ever clicked for me. I understood the concepts, the benefits, but it just felt 'wrong'.
It wasn't wrong of course, there is so much history, ingenuity and the invention of double entry accounting, but I just couldn't get my brain to understand it.
The way the concepts settled in my head was: double entry accounting is just an excellent way of modelling a graph with nodes and edges. Accounts are nodes, transfers are edges. Every edge has a source and a destination.
For a paper ledger, each column is graph node, and each row is a graph edge.
That was enough for me to be able to learn the rest of the things I needed for interacting with the accounting world.
But I also realised that that description really only helps a very small part of the population. :D It makes things so much worse for most people.
"Hey could you help me understanding this accounting thing?"
"Sure, but first thing is, let's learn graph theory! You know who Dijkstra right?"
Whole buckets of nope.
But thats a digression from your actual question - whats the point?
It presents a rigid set of rules of recording transfers, everything has to have a from account and to account (i.e. a graph edge), every row must add up to zero.
Because of that, it makes it easy to spot any mistakes in data entry. If any of your rows dont add up to zero - then you've made a mistake.
I was thinking about how my build of software has changed in the past 25 years, and while it feels there's only been small shifts with a great increase in my general grumpiness at stack complexity, the reality is before AI there had been a huge shift in my day to day focus.
When I started out, writing and reviewing code with a focus on managing memory, performance optimisation, tackling crossplatform compatibility were significant chunks of each day. If you didn't do those things, it was unlikely you would be able to sell in the market, because your competitors were faster or better. Then computers got faster, you needed to think about those things less, and you could instead afford focus more on features and getting to market faster.
Those were distant concerns for most of the things I was working on around 2020. The concerns where instead overall system design, distributed systems concerns, and business processes. If you didn't do those things, your product couldn't compete with all those other ones that did those things well (i.e. multi user systems, scaling to thousands of concurrent users etc etc)
If the AI trajectory continues, code as we know it today will become like memory management or hand rolled assembly from the 1990's, just not something you think about anywhere near as much (right up until the point it becomes a problem). You just couldn't afford not to. The focus and rigor will be in how well have we captured and delivered on the business requirements, how well are we responding to changing requirements, how well are we integrating with other systems. There will be some people who will need work on the low level things things, but the majority of of the sector will be working on these bigger picture problems.
Yes, it will create big balls of spaghetti code, unmaintainable monorepos, and everything today we consider bad, messy and wrong. But when the cost of regenerating said code is drastically reduced, you get to focus instead really close to delivering on user requirements. The focus and rigor will shift to verification, i.e. making sure what we're selling does what it's supposed to. Which If we are honest with ourselves that is exactly what we've been trying to do forever, but we just couldn't afford to do it as well as we would have liked. And honestly it was because building things was more fun and more necessary than testing things. That started to shift 15 years ago, and really shift 5 years ago, and now I think its' about to shift even more.
One could argue much of this doesn't fit under the purview of software engineering, but I think it does. For me, software engineering was the process of capturing value and knowledge in a system that could run on a computer, that we did it using coding, and that many things required highly specialised skills was an implementation detail. It will shift in a way that building architecture did - moving away from the raw technical ability to draft plans, and instead be able to understand a customers requirements, understand the legislation that the buildings exist in, and be able to oversee the project to see it completed that it fits all those things.
reply