IMO, the AI companies are trying to be both T-Mobile and Google Doc at the same time. Even Apple is struggling with being both the platform and the product. The issue with OpenAI is that the platform has no moat (other than money) and the product can be easily copied. In the game console world, the platforms have patents and trademarks, and games are not easily produced.
I'm a retired engineering manager so judge me appropriately :-) I've had 1000 good chats with ChatGPT on a wide range of topics. I build personal Excel and Access applications but not any real programming. I don't need workflow automation although I will dabble with Codex. I'm curious why I should abandon what works for Claude.
You shouldn't. No need to rush to buy a TI-84 to do simple arithmetic. I don't use either because I can learn just find from docs and textbooks. And I don't have that many problems to solve with computing.
And the result was usually a complex system that no one needed and could maintain. Successful refinement is needed when you try to accomplish something from the ground up, refining it as you're adding features. Not locking yourself in the ivory tower drawing UML diagrams and drafting requirements. Doing and thinking go in pair, not separately.
Yeah, the field of software engineering has come a long way since then. But just because previous implementations of the analysis phase were flawed doesn't mean that the phase itself was flawed.
Research conducted by M. Bryce and Associates suggested that use of a structured systems analysis phase before programming began resulted in time and cost savings vs. just "hacking it together" like programmers want to do. Locking yourself in the ivory tower is an unfair way to characterize systems analysis. Systems analysts talk to people in the business to understand what the business requirements actually are, and then design an information system (NOTE: not a computer system or software system; if it cannot in principle be run on pen and paper it is not an information system) that meets those needs. Programmers only come in when the automatable parts of the system need to be implemented, and work from a detailed and precise spec.
> Programmers only come in when the automatable parts of the system need to be implemented, and work from a detailed and precise spec.
A lot of systems are complex enough that you can’t get to that stage (and if you think you do, think again). Mostly because of communication issues and time concerns. Which is where the agile manifesto comes in and recommends the talk-do-show in short cycle. It needs not to be hacked together and the showing helps with communication, the talking guides the doing, and the doing is what pays for everything.
It can be especially bad if the architecture is layered with each one having its own invariant. Like in a music player, you may have the concept of a queue in the domain layer, but in the UI layer you may have additional constraints that does not relate to that. Then the agent decide to fix a bug in the UI layer because the description is a UI bug, while it’s in fact a queue bug
Shit like this is why you really have to read the plans instead of blindly accepting them. The bots are naturally lazy and will take short cuts whenever they think you won't notice.
Unless you’re producing demos for sales presentation (internally or externally), it’s always worth it to produce something good. Bad code will quickly slow you down and it will be a never ending parade of bug tickets.
That depends on how quick the feedback loop is for your decisions. If it takes weeks or months to find the impact of your changes, or worse, if you're insulated somehow from those changes, you may not be pushed toward improving the quality of your code.
But the thing is that someone has to maintain it. And while beautiful code is not the same as correct code, the first is impactful in getting the second and keeping it.
And most users are not consuming your code. They’re consuming some compiled, transpiled, or minified version of it. But they do have expectations and it’s easier to amend the product if the source code is maintainable.
Not really about design, but technical reasons why this solution came to be when it’s not that obvious. It’s not often needed. And when it does, it usually fits in a short paragraph.
What you're describing here is a design. The most important parts of a design are the decisions and their reasoning.
e.g. "we decided on tool/library pattern X over tool/library/pattern Y because Z" – that is a design, usually discussed outside (and before) a commit message.
You discuss these decisions with others, document the discussion and decision, and then you have a design and can start writing code.
Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task?
So you'd disagree with style that Linux uses for their commits?
Random example:
Provide a new syscall which has the only purpose to yield the CPU after the
kernel granted a time slice extension.
sched_yield() is not suitable for that because it unconditionally
schedules, but the end of the time slice extension is not required to
schedule when the task was already preempted. This also allows to have a
strict check for termination to catch user space invoking random syscalls
including sched_yield() from a time slice extension region.
I think my post makes it pretty clear that I would. If you want, I could cite several examples of organizations which use the method I described, so you can weigh it against the one example you provided, and get the full picture.
In your example, for example, where was the issue tracked before the code was written? The format you linked makes it difficult to get the history of the issue.
Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task?
Git was built for email, because that's the system Linux uses. Commits appear inline. Diffs are reviewed and commented inline.
Email is the review process, and commits contain enough information that git blame can get you a reasoning - it doesn't require you checking the email archive. Rather than a dead ticket that no longer exists.
I can also supply you a list of companies that make use of git's builtin features if you like. But thats probably not relevant to discussing management techniques.
Everyone has its own system although companies do tend to codify it with a project manager. I used TODO.txt inside the repo. an org file, Things.app, a stack of papers, and a whiteboard. But once a task is done, I can summarize the context in a paragraph or two. That’s what I put in the commits.
At this point, my phone is PDA level, mostly useful for quick checks. I use a laptop for computing. I know as a tech nerd, I’m far out of the bell curve, but I can’t really bother with those shenanigans unless they’re paying me for it.
Friction is helpful. Putting seatbelts on takes more time than just driving, but it’s way safer for the driver. Current dev practices increase speed, not safety.
reply