The quality of AI-assisted software depends on unit of work management
91–100 of 127 posts
Re: The quality of AI-assisted software depends on unit of work management
#92I seem to be in a minority but I find user stories or features to be really awkward and unnatural units of work for building software. Sure these things help to define the expected result but they shouldn't directly drive the development process. Imagine building a house that way - you don't build the living room, then the kitchen, then the bathroom etc.; you build floors, walls, the roof... The 'features' or use cas…
This isn't a good analogy. When building a house, you are physically realising a blueprint that describes everything in great detail. You know exactly where every wire and pipe should go ahead of time. When there are changes, they must be minor.
This isn't how writing code works. Maybe some management level people would like to believe it can work that way, but it doesn't in practice.
Re: The quality of AI-assisted software depends on unit of work management
#93I seem to be in a minority but I find user stories or features to be really awkward and unnatural units of work for building software. Sure these things help to define the expected result but they shouldn't directly drive the development process. Imagine building a house that way - you don't build the living room, then the kitchen, then the bathroom etc.; you build floors, walls, the roof... The 'features' or use cas…
I kind of like this analogy because it does help us reason about the situation. The one-room shack is basically an MVP; a hacky result that just does one thing and probably poorly, but it is useful enough to justify its own existence. The giant mansion built from detailed architectural plans seems like a waterfall process for an enterprise application, doesn't it?
There are many advantages to building a house one room at a time. You get something to house you quickly and cheaply. When you build each extension, you have a very good idea of how it will be most useful because you know your needs well. You are more capable of taking advantage of sales (my neighbor collects construction overstock for free/cheap and starts building something once he has enough quantity to do so). It's more "agile". The resulting houses are beautiful in their own bespoke ways. They last a long time, too.
The downsides are that the services and structure are a hodgepodge of eras and necessity. If you're competent, you can avoid problems in your own work, but you may have to build on shoddy "legacy" work. You spend more of your time in a state of construction, and it may be infeasible to undertake a whole-house project like running ethernet to every room.
It's all tradeoffs. I think it does in many cases make sense to build a house in this way, and it likewise makes sense to build software this way. It depends on the situation.
Re: The quality of AI-assisted software depends on unit of work management
#94I seem to be in a minority but I find user stories or features to be really awkward and unnatural units of work for building software. Sure these things help to define the expected result but they shouldn't directly drive the development process. Imagine building a house that way - you don't build the living room, then the kitchen, then the bathroom etc.; you build floors, walls, the roof... The 'features' or use cas…
I've been downvoted before for saying my take on this but... Its because SE is a low class low power field. Its not respected by the people in charge at the overwhelming majority of companies. It has resisted standardizing like lawyers, doctors or even real estate agents. So there is little leverage a person in the field can push back with. Its mostly just seen as an annoyance to gaining/consolidating power for the p…
This is the difference with FAANGs. Software engineering is king. The inmates are running the asylum.
Google is at least 4x as efficient as other large companies I've worked for. Nearly every internal process that can possibly be automated is.
Re: The quality of AI-assisted software depends on unit of work management
#95And the value of AI as pushed to us by these companies is in doing larger units of work. But... reviewing code is harder than writing code. Expressing how I want something to be done in natural language is incredibly hard. So over time I'm spending a lot of energy in those things, and only getting it 80% right. Not to mention I'm constantly in this highly suspicious mode, trying to pierce through the veil of my own p…
> Expressing how I want something to be done in natural language is incredibly hard Surprise, surprise… that is why programming languages were created.
Re: The quality of AI-assisted software depends on unit of work management
#96Earlier quoted context omitted.
> Expressing how I want something to be done in natural language is incredibly hard Surprise, surprise… that is why programming languages were created.
Programming languages don’t solve that problem, since someone still has to explain what needs to be done in natural language unless the end customer is also the programmer. Programming languages were created because of the different problem of “its very hard to get computers to understand natural language even if you know how to express what you want in it”.
Re: The quality of AI-assisted software depends on unit of work management
#97Earlier quoted context omitted.
Programming languages don’t solve that problem, since someone still has to explain what needs to be done in natural language unless the end customer is also the programmer. Programming languages were created because of the different problem of “its very hard to get computers to understand natural language even if you know how to express what you want in it”.
I don't but that. In the same spirit, are you telling me that you solve math problems without using any mathematical notation because it doesn't offer any improvement over natural language?
Re: The quality of AI-assisted software depends on unit of work management
#98Earlier quoted context omitted.
Software is not like "building a house" and is not like a sculpture and is not like a cake because software is (mostly) notional not physical.
I don't see the difference. Could you explain how the physical attributes change the analogies?
Re: The quality of AI-assisted software depends on unit of work management
#99Earlier quoted context omitted.
I think most SWEs do have a good idea where I work. They know that its a significant, but not revolutionary improvement. If you supervise and manage your agents closely on well scoped (small) tasks they are pretty handy. If you need a prototype and don't care about code quality or maintenance, they are great. Anyone claiming 2x, 5x, 10x etc is absolutely kidding themselves for any non-trivial software.
if the benefit is less than 2x then we're talking about AI assisted coding as being a very, very expensive IntelliSense. 1.x improvement just isn't much. My mind goes back to that study showing engineers claimed a 20% improvement and measured 20% reduction in productivity -- this is all encouraging me to just keep using traditional tools.
Re: The quality of AI-assisted software depends on unit of work management
#100Earlier quoted context omitted.
I'm starting to kind of dig C.C. but you're right, it definitely feels like a very confident, very ambitious high schooler level developer with infinite energy. You really have to give it very small tasks and be constantly steering its direction. At the end of the day, I'm not sure I'm really saving that much time coaching Claude to do the job right vs. just writing the code myself, but it's definitely a neat trick.…
The thing I am calling BS on is that there's much productivity gain in giving it very small tasks and constantly steering its direction. For 80% of code, I'm faster than it if that's what I have to do. For debugging? For telling it to integrate a new tool? Port my legacy build system to something better? It's great at that, removes some important barriers to entry.