more often than not it’s the development team that skips engaging with users, putting in minimal effort to understand their real needs.
most of these teams only wants a straightforward spec, shut themselves off from distractions, just to emerge weeks or months later with something that completely misses the business case. and yet, they will find ways to point fingers at the product owner, project manager, or client for the disaster.
I have met the occasional person like this, sure. But only ever in really large organisations where they can hide, and only a minority.
The huge majority of devs want to understand the business and develop high quality software for it.
In one business I worked for, the devs knew more about the actual working of the business than most of the non-IT staff. One of the devs I worked with was routinely pulled into high-level strategy meetings because of his encyclopaedic knowledge of the details of the business.
The mistake is in trying to understand the business case. There is nothing to understand! The business case is the aggregate of what people actually do. There is no proper procedure that's actually followed at the ground level. Workflows are emergent and in constant flux. In this environment, the role of a dev should not be to build internal products, but to deliver internal hacks and ad-hoc solutios, maintain them, modify on the fly, and keep it all documented.
I.e. done right, it should be not just possible but completely natural for a random team lead in the mail room to call IT and ask, "hey, we need a yellow highlighter in the sheet for packages that Steve from ACME Shipping needs to pick on extra evening run, can you add it?", and the answer should be "sure!" and they should have the new feature within an hour.
Yes, YOLO development straight on prod is acceptable. It's what everyone else is doing all the time, in every aspect of the business. It's time for developers to stop insisting they're special and normal rules don't apply to them.
It would be nice if the computers could be that nice to work. It’s a completely dumb machine that needs everything spelled out. Humans are very flexible. To get flexibility out of a computer require great effort.
The main reason you want a computer is cheap emulation (cad, daw,…) or fast (and reliable) automation. Both requires great deal of specifications to get right.
Are you sure? Almost all excel sheets are emulations of some process. They’re not great at it, but they work better than the alternatives. But organizations need automation more than emulation, i.e. they want to improve their process, not merely replacing them.
Those sheets are not emulations of some process, they are the process. There is no perfect, platonic process, that the Excel sheets are merely shadows of. There is no fixed goal to approach iteratively. The process is defined by what people do, and it's improved by them through adjusting to situations as they occur and eliminating waste - and creating and evolving these Excel sheets is part of this continuous improvement.
Top ends of organizations need and want a lot of dumb, self-defeating things - this is very much the same thing that's described in "Seeing Like a State". Doing this blindly is, of course, a prerogative of the executives, but internal IT is actually low enough in the food chain that it could focus more on helping the org by improving the bottom layers, instead of embracing and encouraging the top to create more rigid structures.
EDIT: to refer back to the example I gave upthread:
"Steve from ACME Shipping" is not meant to be a special case of an "external vendor assigned to auxiliary shipping itinerary"; the system needs not to be designed to express the concepts of "external vendor" and "auxiliary shipping itinerary" and "shipping itinerary assignment for shippable resources". Steve is just Steve, the whole "extra evening run" thing is probably just a one-off emergency measure for Q3 that will disappear come Q4 (or persist, and then some executives will start talking talk about deeper changes to mailing process). Right now, all the mailing room needs is for someone to add a boolean flag:
// Steve from ACME Mailing
bool boundToACMEEVeningRun;
and hook it up to a button that sets it and logic that displays it with a yellow highlight. And yes, this means all that code will likely need to be thrown away next month (or rather, gated by a config flag so versioning/audit trail still works). Making it work out is what the dev is paid for.
The thing about that is that you can only ever YOLO the superficial layers of your architecture, and only ever in certain ways. Having a YOLOable system requires deliberate and considered architectural choices deeper down.
YOLOable systems are built out of flexible pieces. That's why Excel "abuse" is a constant theme in enterprise :).
We should not be thinking about architecture at the business process level. This is just repeating the mistake that needs to be avoided here. This is, and will ever be, a pile of ad-hoc hacks. They're not meant to add up to a well-designed system in a bottom-up fashion, because there is no system to design. The structure we naturally seek, is constantly in flux.
The right architectural/design decisions to make here is to make it possible to assemble quick hacks out of robust parts that fulfill additional needs the people on the ground may not consider - logs/audit trail/telemetry, consistency for ergonomic reasons, error handling, efficient compute usage, tracking provenance, information access restrictions dictated by legal obligations, etc.
The most important change needed is in the mindset. Internal dev needs to stop thinking of itself as the most important part of the company, or as a well-defined team that should own products. To be useful, the opposite is needed - such devs need to basically become ChatGPT that works: always be there to rapidly respond to requests to tweak some software by people on the ground, and then to retweak is as needed. They need to do this work rapidly, without judgement, and never assume they know better.
Only then people will stop weaving ad-hoc Excel sheets into business-critical processes.
And yet, even ”knowing about the working of the business” is different from actually understanding user needs at UI level, which involves a lot more variables.
The single most valuable tool is user testing. However it really takes quite a few rounds of actually creating a design and seeing how wrong you saw the other person’s capabilities, to grok how powerful user testing is in revealing your own biases.
And it’s not hard at all at core. The most important lesson really is a bit of humility. Actually shutting up and observing what real users do when not intervened.
most devs complain about management tying their hands but more often than not they have a great deal of control over the tech, libraries, or frameworks adopted. these are the biggest culprits behind crap software.
if adding a new feature or button significantly slows your app, and you had a role in the architecture, you have no one to blame but yourself
I'd expect non tech people clueless about how AI works to miss the gap between humans and machines, but it's baffling how many here fall for it too. Every discussion about AI and copyright spirals into these brain dead examples of false equivalence.
It's like saying a lone fisherman and a 50m industrial trawler both catch fish, so they should be bound by the same rules and regulations. It's absurdly reductive and pathetic not to notice this error
so far the best models are controlled by fewer than a dozen labs. access is limited, full of restrictions and guardrails, and most are expensive, especially video models. also, open weight models deliver far inferior results, and hoping they'll catch up is, for now, just hope.
as an artist, I totally agree with this approach. the whole idea of trying to pay artists for their contributions in training data is just impractical.
if the data’s pulled from the public domain, the model built from this human knowledge should be shared with all creators too, meaning everyone should get access to it
and how do you reconcile any work in software development? If someone isn’t willing to work for free, should they just not work in the field at all? Do you think software culture would really be richer?
My income is tied to the labor time I exert in creating/supporting services. I don't sit back and collect royalties on the code itself. Software is one of the first fields where the fundamental worthlessness of content revealed itself, hence FOSS.
When you watch a musical performance, you are also paying for labor. Even when you buy a physical art object, all the costs involved decompose back to labor. When you have a digital copy of something, there is no labor input to its creation, so guess what the inherent value is.
Animators drew actual cels. Theater workers clocked in and screened the films. The guys at the DVD factory pressed the discs. We paid for all of this already. It's double-billing to charge for copypasting the mere likeness of something. Nobody's doing any work for that.
you’re allowed to tie your income to creating systems precisely because you’re not allowed to copy them from previous companies or other sources
selling software isn’t much different from a musician collecting royalties, especially now when everything’s shifted to a subscription model.
it lets us keep pretending we’re adding value, even though most of them often stays the same for years
Sorry, but I don't buy it. It's not like we're milking a secret golden algorithm. If all my company's code were open sourced tomorrow, I don't think a competitor could do much with it, since they'd just be presented with bog standard CRUD. It's still relationships and sweat that's keeping the lights on for the time being.
It's a major hindrance. For example, if I came up with an amazing creative idea for a star wars movie I couldn't do a damn thing with it unless Disney told me I could. Disney isn't likely to accept an unsolicited pitch from a total nobody who just happened to have a great idea either. I don't see how you could doubt that there are a lot of great works of art that won't ever exist because of the fact that copyright prevents them from ever getting off the ground.
Copyright can stop me from making a star wars movie about wizards fighting each other with laser swords in space. Even if I don't make a star wars movie, if I make a movie that makes disney feel threatened because it's close enough to being a star wars movie I could still end up losing in courts.
There are plenty of examples of copyright hurting people for creating something that wasn't exactly the same as something else which was copyrighted. Copyright is a threat to all creative works. The bigger the investment required for a creative work, the bigger the risk. For this reason, we see it a lot more often in music where the investment needed is lower than films. People have been successfully sued because they wrote a totally new song that was in the same genre as someone else's song https://abovethelaw.com/2018/03/blurred-lines-can-you-copy-a...
maybe most of the code in the future will be very different from what we’re used to.
For instance, AI image processing/computer vision algorithms are being adopted very quickly given the best ones are now mostly transformers networks.
most of these teams only wants a straightforward spec, shut themselves off from distractions, just to emerge weeks or months later with something that completely misses the business case. and yet, they will find ways to point fingers at the product owner, project manager, or client for the disaster.