“I’ve been saving for months to get the Corsair Dominator 64GB CL30 kit,” one beleagured PC builder wrote on Reddit. “It was about $280 when I looked,” said u/RaidriarT, “Fast forward today on PCPartPicker, they want $547 for the same kit? A nearly 100% increase in a couple months?”
IMHO, most people’s time usage perception tends to be heavilly skewed toward weighing higher the time taken in the main task - say, creating the code of a program - rather than the secondary (but, none the less, required before completion) tasks like fixing the code.
Notice how so many coders won’t do the proper level of analysis and preparation before actually starting coding - they want to feel like they’re “doing the work” which for them is the coding part, whilst the analysis doesn’t feel like “doing the work” for a dev, so they prematurelly dive into coding and end up screwed with things like going down a non-viable implementation route or missing in the implementation some important requirement detail with huge implications on the rest that would have been detected during analysis.
(I also think that’s the reason why even without AI people will do stupid “time savers” in the main task like using short variable names that then screw them in secondary tasks like bug-fixing or adding new requirements to the program later because it makes it far harder to figure out what the code is doing)
AI speeds up what people feel is the main task - creating the code - but that’s de facto more than offset by time lost on supposedly secondary work that doesn’t feel as much as “doing the work” so doesn’t get counted the same.
This is why when it actually gets measured independently and properly by people who aren’t just trusting their own feeling of “how long did it took” (or people who, thanks to experience, actually do properly measure the total time taken including in support activities, rather than just trusting their own subjective perception) it turns out that, at least in software development, AI actually slightly reduces productivity.
I disagree here. You can try to build everything out theoretically and then realize the issues once you have a massive thing that does not work. This is literally waterfall vs agile. Iteration is a proper way to do things. As far as AI im not sure it speeds up coding vs companies that will purchase the addons and programs that already can speed it up. I have seen so many companies push back on purchasing jet brains but it seems like ai spend is unlimited.
I think you’re confusing doing analysis before coding with doing all analysis before coding.
If you do Agile properly (so including Use Cases with user prioritization and User feedback - so the whole system, not just doing the fashionable bits like stand up meetings and then claiming “we do Agile development”) you do analysis before development as part of evaluating how long it will take to implement the requirements contained in each Use Case. In fact this part of Agile actually pushes people to properly think through the problem - i.e. do the fucking analysis - before they start coding, just in bit-sized easy to endure blocks.
Further, in determining which Use Cases depend on which Use Cases you’re doing a form of overall, system-level analysis.
Also you definitelly need some level of overall upfront analysis no matter what: have a go at developing a mission critical high performance system on top of a gigantic dataset by taking a purist “we only look at uses cases individually and ignore the system-level overview” approach (thus, ignoring the general project technical needs that are derived from the size of the data, data integrity and performance requirements) and let me know how well it goes when half way down the project you figure out your system architecture of a single application instance with a database that can’t handle distributed transactions can’t actually deliver on those requirements.
You can refactor code and low level design in a reasonable amount of time, but refactoring system level design is a whole different story.
Of course, in my experience only a handful of shops out there do proper Agile for large projects: most just do the kiddie version - follow the herd by doing famous “agile practices” without actually understanding the process, how it all fits in it and which business and development environments is it appropriate to use in and which it is not.
I could write a fucking treatise about people thinking they’re “doing Agile” whilst in fact they’re just doing a Theatre Of Agile were all they do is play at it by acting the most famous bits.
I really don’t think anyone is jumping in with zero analysis. Granted I have known some who will jump into something when its just a few words or even before its decided to go forward with a solution but over half the time what they do overnight provides decent info on moving forward or is helpful for gathering requirements. I mean im not blowing out my evening on a maybe but I respect the passion.
I would describe it as “insufficiently thinking about and researching the problems space”.
From what I’ve seen that’s very common because developers have a tendency to want to be hands-on rather than merely researching, myself include.
Even for the sake of figuring out inconsistent requirements or even just big gaps in the requirements, it’s a good idea to really think about it and cross check things.
Personally, the more I advanced in my career and the more complex and larger problems I had to tackle, the bigger the fraction of preparation time vs the fraction of coding time and I believe most very senior devs have the same experience.
Honestly the biggest problem I see is not getting requirements but being pushed for deadlines. I have been in monitoring solutioning lately and we constantly can’t get answers from teams on what they need and end up having to just analyzed the data as non specialists and do a best guess because we can’t just not have the solution happen.
Well, seniority helps on the deadlines front: you can spot managers trying to force too short deadlines on you a mile away and throw it back at them (“I’m am the specialist, so I’m the one who knows best how long it will take”) and if they just try and impose deadlines you can bluntly state “that isn’t possible” and if they somehow have the authority to push them you make sure everybody (especially other managers, ideally the managers above them) knows that you’ve informed them upfront that such deadlines were impossible so when it inevitably fails, said manager can’t shove the blame your way.
As for obtaining things from other teams, that’s a two part thing:
Of course, all this requires competent management since they’re the ones supposed to do it and if your managers are trying to impose deadlines on you or using slimy trickery to get people to commit to shorter deadlines, they’re NOT competent managers - that kind of shit invariably yields death marches and bug-riddled results that in the mid and long term end up wasting far more time that it was shave by those shorter deadlines.
Kinda sad that one has to play such games. Welcome to Mankind.
yeah although in the situation Im talking the issue isn’t the deadlines vs the technology we are configuring but in not getting the requirements from the various specialists for what they want out of it. I have encountered things like it all the time. Each team has their own priorities and they won’t really put in the effort until they are actually using the product regularly and then decide what they want out of it because its not giving them exactly what they want. Honestly can’t say it upsets me to much as ultimately it keeps me employed longer.
Most people don’t actually know what they need until the see it, and the only ones who might are those who already have a process in place (hence know it in detail) and just want it or parts of it automated.
People often do think they know what they want, but it’s a very general and fuzzy view, with little in the way of details and which seldom considers what should happen outside the most thread path of their process (i.e. things like error situations such as “what if somebody enters the wrong data in this form” or after the fact responsibility tracing in the form of usage logs and reports).
It is actually a bit of an art to tease the details of the requirement from the stakeholders in a consistent and thorough way and also spot and get requirements for those “outside the main process path” elements and, frankly, in my career I’ve met very few people - even amongst business analysts - who are actually good at it.
That said, what maybe the main advantage of Agile when done properly (with proper use cases and the actual end users trying the implementation of those requirements out) is exactly that it’s an interactive process to refine the requirements by cycling back and forth between requirements gathering, feature development and result evaluation to fill in missing details and tease out further requirements. IMHO, this is actually were Agile shines the most when compared to Waterfall, but as I said you need to do the requirements gathering and results evaluation parts of Agile (so the parts involving interacting with actual users bot upfront in making use cases and at the end of the cycle in evaluating the fitness for what they need of what was implemented) to get those gains, and most “Agile” teams out there seem to only do the fashionable parts of Agile like the “standup meeting” which aren’t what makes it most valuable as a process.