Using Claude Code for embedded work

[Siwastaja]

AI will not fix it.

I agree AI will not fix the software industry. I see a glimpse of hope though: now teams of 1-5 people who know what they are doing can act much bigger than before. This democratizes the field and makes new type of competition possible. You don't have to be a 100-coder huge software house, or a 100-volunteer open source project gathered during 10 years, to do a large software project anymore. You don't need 10 millions of investor money, then try to hire 20 coders, only to find out 18 of them are "off the street" and do not know what "release notes" mean.

And if I'm right on that - it could be a big shift. Smaller, faster teams - more development efficiency. Less waste. More competition. And competition is always a good thing. Big part of the reason why software industry has lost the ball is, as you point out by your 2020 observation, is demand exceeding supply, so anything goes; any outcome must be accepted, because no one else can do it any better. Competition fixes that, and classic, large software houses have to solve their own problems - with or without AI.

[paulca]

Maybe.  Maybe not.

"Completion" and "Closure" in projects are not longer advantageous.  "Working and complete" software does not write cheques.  Not really complete, yet anyway, software extended contracts, adds monthly cheques.

They don't want you to complete a project as working.  That cuts the revenue off.

So it's not completely "incompetence" it's just that with a critical mass of "non-engineers" it's "acceptible for business".

What they don't realise is... it is a violation of my core values as an engineer and they don't care about my sanity. I am not alone.  GenX are getting close to retirement.  The rest of the boomers left around covid.  Once GenX start leaving they have no more 'Ravens' to keep the tower up.

Also.  The dynamic that is actually happening is that 10 completely clueless juniors armed with claude produce 10 pull requests of code which the sole senior engineer is responsible for reviewing, correcting, and approving.  They are not writing code, they are not designing systems, they are doing code reviews of AI generated code 110% of the time.

[Siwastaja]

Also.  The dynamic that is actually happening is that 10 completely clueless juniors armed with claude produce 10 pull requests of code which the sole senior engineer is responsible for reviewing, correcting, and approving.  They are not writing code, they are not designing systems, they are doing code reviews of AI generated code 110% of the time.

Small, fresh teams are free from these kind of structures. If you are the "senior engineer", and you are using Claude, you don't need to even generate pull requests, let alone check others' crap.

Clueless juniors armed with AI seems like the worst thing to happen, and if that's happening in the software industry now, I don't have much hope. But that depends. MAYBE if they are taught to use AI to pre-check their work before submitting PRs - that  could improve quality and reduce the burden of the sole senior engineer. But, instead, if they are pushing new features with record speed without understanding what they are doing because upper management said we can ship features faster with AI - oh dear.

[peter-h]

It works fine in small companies.

It is the bigger ones which have always had problems - because (in the post Apollo era ) you cannot assemble a big team of good people. I think Claude etc will create havoc there. They will probably just get stuck in legal debates about who owns the copyright

[Kjelt]

Its been going on for a long time in sdev.
I switched companies ten years ago to find out that the new company which is globally known for their products, delivers poor quality software. They switched to SaFe, output dropped factor two, people increased factor two mostly supporting middle management know nothing , but talk the talk.
It took four weeks to get the teams to get a proper "definition of done" 
And now we have a proper definition of done noone follows it since that would drop output with another factor of two.
But that is doing software the right way with proper requirements, desig, implementation, testing, documentation then delivering.
Noone does that, all cut corners. It should be finished and delivered yesterday.

Documentation was never completed since 1999, a few brilliant engineers that wrote the code and are about to retire have it in their heads the youngsters often hired from all over the world struggle to cope.
I have seen four companies in my career and none of them thought software was equally important as hardware. Hardware was king and if the electrical engineers screwed up with their design what does happen, software should fix it which as we all know is only partly possible.

So this has nothing to do with AI or  new generation or young people, this has been going on since late 90s when any university graduate such as biology and history graduates were hired as sw engineers and the industry was low on real engineers.
So perhaps the real SW houses have their staff and methods properly in order, I can not say this for any hardware product company I have ever worked for the last 30 years.

[paulca]

Small, fresh teams are free from these kind of structures. If you are the "senior engineer", and you are using Claude, you don't need to even generate pull requests, let alone check others' crap.

Remember I work in a regulated evironment.  Also remember that the UK state makes no differentiation between "Engineer" and "Chartered Engineer" when it comes to "Negligence" and other crimes.

Also remember that Horizon's scandal is still fresh in people's minds.

Then recant the AI First directive.  "Nobody writes any code.  You don't own the effort, you own the output.", "You are responsible for the AI output."

So if people loose houses, fortunes, lives, I am still summonable to court as an individual.

The irony is... the management and the juniors DONT.  They cannot be summoned.

[az1]

So this has nothing to do with AI or  new generation or young people, this has been going on since late 90s when any university graduate such as biology and history graduates were hired as sw engineers and the industry was low on real engineers.

You can make bad software without AI, but you can't make good software with AI.  Look at Anthropic. They've tried to vibe code a Javascript runtime and ended up with a giant pile of slop.  The race to the bottom isn't new but AI being used as a force multiplier in that race is.

[peter-h]

but you can't make good software with AI.

That's probably true if you use e.g. Claude to generate the whole lot.

[SpacedCowboy]

It works fine in small companies.

It is the bigger ones which have always had problems - because (in the post Apollo era ) you cannot assemble a big team of good people. I think Claude etc will create havoc there. They will probably just get stuck in legal debates about who owns the copyright

That may be true for medium-sized companies. It's not true for the true giants. I'm recently retired, but I worked at Apple for 20+ years, did some cool stuff myself, and worked with a lot of amazing people. They pay a lot of money, and although Apple may have a "fluffy bunny" consumer-orientated exterior, they're a ruthless machine on the inside, fortunately expressed as (mainly) a meritocracy. People who weren't worth that money were soon encouraged to ... find employment elsewhere.

Apple also has the concept of the DRI - the "Designated Responsible Individual". All projects have at least one DRI, larger ones are split into areas of responsibility. Sometimes that DRI is a director, other times it's an intern (we didn't give interns much R, it was more "this is how we work, muck in"). We did give relatively fresh employees R though, and that worked fairly well - there was always oversight from the team lead for the first time, just to show them the ropes, but after that, you were the DRI. If that meant arranging a conference call with Amazon or Microsoft, that's what you did (after talking to your manager . If it meant finding the off-by-1 error in an icon on-screen, that's what you did. At the end of the day, anything wrong in that scope was yours to fix or manage. As a means to integrate collective responsibility for the product, it worked really well.

No, I don't understand how Liquid Glass ever got released as-is. Not my area of R.

[SpacedCowboy]

but you can't make good software with AI.

That's probably true if you use e.g. Claude to generate the whole lot.

I'm going to come solidly down on the "maybe" line, here. I've had some awesome success with xtc - and I'm pushing even further on it now, I'm in the middle of a re-target to create an intermediate representation between the front-end and the back-end, so it can target more than just the 6502 and which opens up even more possibilities for optimisations.

Writing a (good) compiler is a big job, and it's taken Claude (not me, just "him") about a real-time month of effort so far, which is ... stunningly quick. It produces code within grasping-reach of hand-optimised assembly for the 6502 (benchmark runtimes of ~11 secs whereas the best hand-optimised is ~10 secs, there's also hand-optimised that's ~20 secs...), and creating a language with automatic memory management built in, classes, interfaces, inheritance etc., on such a limited CPU is quite the technological feat, IMHO.

I can imagine the wails if I'd walked into an engineering meeting and announced that I wanted the team to take that toy, demo-version piece of software and start turning it into something a lot more heavyweight - without that being the plan all along... With Claude it's just "ok, let's do this, and that, and as an optimisation we should <insert random thing I've never heard of, go google, and realise it's exactly the technique to use, "Sparse Conditional Constant Propagation", this time, if you care>

I sometimes drag it kicking-and-screaming towards what I want and not what it recommends, sometimes it suggests things I have to go look up before I agree with them, sometimes I plain say "no, that's not the direction". You still have to be in control to get the result you actually want, but it does take away a lot of the typing and leaves you free to do a lot more thinking.

It also allows for more exploration, because of the lack of that typing. My "6502" is on an FPGA... last night I was musing about how different the cost is of using the hardware stack (limited to 255 bytes in page-1) and the software stack (where all the arguments to functions actually get pushed, because otherwise your call-depth is about 6 on complicated functions). PHA is a single instruction, the software stack has to have space in zero-page, and indirect through it, takes 4-5 instructions. What about if we gave page-1 infinite depth ? Just have a public 8-bit SP but really it's 16-bit ? Well TSX/TXS would be a problem but that's about it. Okay, do the same for X. Hmmm. If it's documented and the compiler uses it, massive win for any function call...

I think there's still a lot to be said for the old adage "garbage in, garbage out". I can see it would be easy to just agree with it all the time, and ... that would not be a good path to go down ... so you still need the knowledge (or some way to verify and understand what it's telling you at least) but with that said, I'm having a surprising (to me) amount of success with it.

[peter-h]

I'm recently retired, but I worked at Apple for 20+ years

OK; Apple is obviously a smart company. An old friend worked for Cisco (left about 15 years ago) and he often said he never worked with more intelligent people anywhere else in his life. He doesn't think that is true for today's Cisco, but who knows?

So, yeah, one cannot generalise totally re big companies. On the whole they must be well managed (otherwise your FTSE100/S&P/etc trackers would be junk ) although hugely benefiting from the rule that 80% of your profits come from 20% of your customers, which enables you to have crap customer service etc and screw around an awful lot of existing and potential customers and still be huge. Honeywell, anyone? Every company they buy they f**k up. I know of some good aviation examples.

I think Claude is a brilliant tool, but then I've been around long enough to know where the skeletons are likely to be buried, and I use it for well defined tasks.

[paulca]

The bigger the company the bigger the mess.  The bigger the cost to fix it.

So the graph looks like a mosfet resistance chart.  Smaller companies tend to have more messy stuff but less of it.  Large companies have less messy stuff but far more off it.  Only the really large ogranisations can dump millions and millions of dollars into internal software departments.

The rest are left to get vultured by the consultancy rapters.

However the appreciation of why its so difficult I feel is often lost in here.  You seem to always reference "concrete" and "static", well encapsulated projects.  This is perfectly normal for the embedded space, but is not how the rest of the world works.

The key metric is that all my landscapes, requirements, tech stacks, platforms, customers.... are all in motion and not in sync most of the time.  Consider that for a while.  Consider if your MCU manufacturer is updating the peripheral register contents weekly.  Your customer requirements can change in a day.  By the time you get 2 months in the process there will be at least one C-Level event that changes everything under you.

You are smart enough engineers to understand that independently moving, unsynchroised complexity and dependency is a "Multiplier" on complexity, if not exponential.

Compilers and battery analysis reporting.  Almost "single component" except the later I expect isn't.  Try zooming out until you can see something like "A state transport department internal systems rework".  Think in that kind of scope and like all of us wonder how anything works.

[Siwastaja]

So the graph looks like a mosfet resistance chart.  Smaller companies tend to have more messy stuff but less of it.  Large companies have less messy stuff but far more off it.

I would not fully agree with that. I know perfectly what you mean, but it depends on the definition of "mess". Larger companies tend to have more complex processes which to many, probably you included as a professional, seem "tidy", the opposite of mess. For an amateur like me, many software industry proven practices look like mess.

Our situation was interesting. We are a very small software company and we had the large company process syndrome. 90% of our effort was spent on processes. Ticketing, managing the tickets, writing, rewriting, and re-re-writing CI/CD chains and server infrastructure setup. Doing "technical debt removal" on working parts, after which they worked more poorly and had more technical debt. Actual payload, the features customers want and need, and fix bugs in existing necessary features, was PITA trying to squeeze it in, somewhere in this schedule full of meta processes.

Big companies are like that. And for those in the industry, it might look tidy and nice. Well organized. But does the actual product work? Does the actual work get done? That should be the only metric.

Small companies who have small number of programmers and simple processes look "amateurish" due to lack of processes but whether that actually leads to any problems is the big question. I have stopped believing when professionals talk about technical debt or processes. Professional programmer's #1 sin is always crying the wolf technical debt, or lack of processes, and it's always serious and always "prevents all work" and "makes the company fail in long run". My experience shows it's better to take the "risk" of keeping developing the core product. Every software project will end up more or less messy, with technical debt. Any process won't magically fix that, but processes do reduce efficiency, slow down development - including bugfixes which are important for code quality, so processes would need to be really good to be beneficial, and it seems it's very hard for the software industry to actually define what is a good process.

So, IOW, small companies make "mess" only if you look at them through the software-industry colored glasses and expect to see certain patterns, but there is no conclusive proof these patterns actually are any good. If they were, they should be handling "more of the stuff" just fine.

[paulca]

On process it depends on who generates the process.

If engineering formulates and generates the process it's usually fine.

Trouble is, there are less and less of people capable and knowledgable enough in the field to know where to look, to have an existing pallete of processes from actual engineering accumulated knowledge from trial and error, measure and test over decades.

In fact the critical mass has been exceeded in the other direction.  There are now more unqualified and uneducated people holding the Software Engineer title than qualified.  So the entire language and positioning, even conversations have changed.

Without any map, tool pallete or recall of a degree explanation of why "Requirements first" is a must etc. etc.  They don't see any of it.  When they do they start reinventing processes, sometimes they arrive at something useful like "Release Notes" and others they end up somewhere deeply dangerous.  In the later you protest and get told to stop being the blocker to progress.

For them, the ceremony, the process IS the work.  They have no mental model to engage with on the actual work.  There are more of them than us.  That is why the industry is in free fall.  The space real work gets done and the processes that held it together no longer exist.  Not outside of maybe, aerospace, nuclear, defense et. al. and maybe capital markets.  Places where consequenses are almost immediate and almost always VERY expensive.

[paulca]

Consider a single word.

Agile.

Immediately people separate into two camps.  Those who see the implementation of it and try and work out the intent from that and ... hate it, realise it's a curse.  Then there are people who read the actual agile docs, guidance and recommendations and understood them and think, "It is actually useful and valid."

The problem is that both are true.  Agile was presented by engineers who knew what they were doing.  It was meant to empower the dev team to take ownship and avoid long decision chains.

What got implemented was a weapon used to break rigor and delays for quality and clarity.  "We don't need to know what we are building, we'll just make it up for each sprint as we go, it'll be fine, customer is paying".

EDIT:  The actual agile king pin they removed was, "An item can not enter a sprint from the backlog until it has no decisions needing to be made external to the team."  Put another way, a work item is only accepted into a (usually) 2 week completion window when it has no external dependencies and only the dev team responsible.  Management just deleted that single premise and destroyed agile instantly.  Turned it into a weapon.

The belief that all mistakenly written code today can be refactored into it's own purity tomorrow and again next week is utter bollox.  You either have clean code written to a purpose or you have a dirty mash of intent and bugs.  There is no middle ground.  So the wise start over.  You can do things in two ways.  Right and again.  But the business doesn't care about again, they just get more cheques to cover it.  Each again, erodes you engineering soul though.

[peter-h]

"Agile" is a standard corporate-BS expression

[Kjelt]

"Agile" is a standard corporate-BS expression

Nope it is replacing a half year or longer waterfall model by two weekly sprints or small waterfalls, quickly identifying a mismatch between the wishes and requirements of the customer and the software companies interpretation. It works great for some companies and some software teams and lousy for others. If you ever had to build software for a customer where the customer does not know himself what he exactly wants and making requirements is a project on its own and after a years work the customer does not recognize what he ordered, that is what happened a lot in the past. Unfortunately it does not work that great for hardware and also not when there is no regular customer review and feedback. Great for GUI's , less for embedded and lousy for hardware, because cycles are way longer and final product less visible/touchable to customer so it lacks the needed quality of customer feedback.

[Bud]

It has nothing to do with Agile if the customer does not know what they want. Agile is a f-king waste of time and resources. Before Agile, a team of 5 did the work. Now with Agile, same work is done by 10 people, 5 of which are scrum masters, agile coaches, and other agile ballast.

[Siwastaja]

"Agile" is a standard corporate-BS expression

Nope it is replacing a half year or longer waterfall model by two weekly sprints or small waterfalls, quickly identifying a mismatch between the wishes and requirements of the customer and the software companies interpretation.

That's what the original idea exactly was. However, if bureaucracy and slow processes are in your "DNA", then switching to "Agile" to check a box means you are going to add all the processes from Agile to your workload, without getting any more work done.

The problem with codified ticket-based systems is that tickets lose a lot of information, unless you spend massive amount of time with them. Just good old discussion - chatting - with other workers is invaluable. Called co-working. This is also why AI seems to work so well - the interface is chat-based, and unlike human workers, it's always available and responsive.

Software industry incorrectly compares itself to first designing blueprints for a house, then constructing the house following the blueprints exactly. Analogy is sound in theory, but misapplied: most of the work we think is just "implementation" is actually the "making the blueprint" phase, and that's all the work. And that requires very strong communication. Waterfall locks it down completely possibly for a year, but Agile isn't much better if it's locked down for two weeks; the core issue is the same, it should have not been locked at all, the design work must be continuous iteration. Tickets work well for describing bugs found and random feature requests from customers. I question the usability of the idea of having a sprint start meeting, after which the epic is ticketed into 57 sub-tasks that are then fixed for the next 2 weeks and divided to 5 workers.

The best thing in Agile is the idea of finishing smaller sub-projects and shipping them to customers. That's actually great and prevents building a monster which was not what customer wanted and which does not work.

[paulca]

Pretty close, except the epic and sprint diviying.

The locking in is meant to stop the single most delaying aspect of software.  Change during implementation. 

Without Agile, the customer can and will interrupt you mid ticket and say, pause that one, do this one instead.  They just don't understand what that actually causes.

In traditional Agile.  The epic and tickets are broken down with the "Product owner" and "Dev Team".  The sprint planning stare-mony is meant to be where the team negotiate with the scrum master/product owner and the business utltimately, what is "realistically achievable" in the sprint.  The "goal" is to have a well feed team, a set of tickets which will complete before the end and any slack can be taken up with a few tickets left in to the backlog in a "Can be pulled into Sprint" label.  ie.  tickets that are 'ready for dev'.

At the end of the sprint, "velocity" is recorded as to how many tickets or what size the team actually got through.  This metric is use back at the next spring planning as a "This is the bucket size" measure.

Of course, as well all agree, "business" didn't understand it, could not accept that it does not give a "What and When" at the same time, but their invoices do.  So they.... adapated it to suit themselves.   Turning it against the dev team.

EDIT:  The alternative is where I am right now.  You get a ticket.  You read it.  You might be able to start it, you might not.  Usually there is missing information, nobody thought to include.  So I ask who to ask... then I wait... Then I find out who to ask, so I ask.... and wait....  Meetings are arranged, talk happens, no decisions, so I wait.  Eventually you have 20 tickets sitting on the board and none of them can move.  Some of them have been started, some haven't.  Some part of the business are wondering why nothing is moving or closing while other parts of hte business not talking to each other are taking their sweet time giving answers.

[Siwastaja]

The locking in is meant to stop the single most delaying aspect of software.  Change during implementation. 

But locking in to wrong things, implementing them, waiting for two weeks, then reverting them, and doing them again is exactly what causes delay. Especially because now you have something new planned for the next sprint, so realistically you won't be re-doing your previous sprint, no, you go forward and add a new feature instead. This is exactly how technical debt gets into the project. Then developers want to redo everything every 1-2 years.

Sure, developers need to be able to filter out whimsical and unnecessary change-of-minds. Understanding customer intent instead of doing exactly what they said is the key.

But it's not only customer requirements. What gets locked too are implementation details, APIs between the parts maintained by different people. If you get those wrong, then the codebase is full of workarounds and workaround for workarounds. That's exactly the "technical debt". During implementation you will find out "hey, if we do this different way instead, everything gets much simpler"... The fewer there are people implementing, and the more they communicate together, the better it gets.

[paulca]

I don't deny you that.

For me I see/feel gradients of certainty and stability.  Engineering bath tub curve applied to many things.  Including requirements.

Without calling it 'waterfall', it is advantageous to put strategic resistance into the process.  The developer mental model pool is limited.  When you allow more to flow into it, it will just overflow.... down stream as bugs and technical debt, which cost more later to fix.

Placing a 'weir' on the sprint entry allows turbulence in the requirements stream to not upset the dev pool which is working on the last generation that was allowed to flow over the weir.

Does that analogy track?

In concrete terms, we have "DRAFT" status, "AWAITING APPROVAL" etc. etc.  In some workflows at least.  On the other end of the development the releases, in well managed flows, have things like, "DEV", "RC - release candidate", "EXPERIMENTAL", "ALPHA",  "BETA", and finally, "STABLE".

Its the same response to the bath tub curve I mentioned above.  Resistance in the flow deliberately to give things time to "settle" and become "proven" and thus "load bearing" for the next work.

Finding that ideal workflow out there in the current software industry is like hens teeth though.

EDIT: On exploring this with AI it keeps reframing it back at me as:  "Velocity is more important to consultancies than actual progress", Agile or the agile bastarisation that exists provides the appearance of velocity making actual progress almost a byproduct.

[paulca]

To complete that analogy of the "Mean time between failures curve".  The rise at the other side where the failure/error rate rises again is obscelence.  In terms of software, the original purpose and platform has changed so much that the component can't hold it contract anymore and fails.

In terms of requirements.  If you take too long to delivery to requirements, the business moves on, evolves and the requirements change.

It is the later which is causing so much 'velocity' tracking in software today... the full graph from "birth" to "its too old and doesnt match teh business direction", is now measure in months.  Not decades.  If you can't built it and get it to market in 6 months, it's not worth doing.

[Siwastaja]

If you can't built it and get it to market in 6 months, it's not worth doing.

Usually that's true, but not because everything is changing so fast. Not at all - in fact many needs stay pretty much exactly the same for decades, even tech stacks are pretty stable for many years. If someone chose to implement something with node js 7 years ago, it's mostly still valid work today.

No, the real reason why you are correct is that if something is taking significantly more than 6 months, it's an indicator you are doing it ineffectively - your processes are clumsy, and it's expensive to run these processes which cannot deliver anything in 6 months. Because most of the projects are not really that complex. In almost all cases, you should be able to deliver something very usable, if not a fully perfect complete product, in just a few months.

Counterexample would be the one guy posting here who proposed that a phone app that plays music synchronized to workout patterns takes many years to ship, and even a simpler, useful "first release" cannot be made in less than years, and that huge amounts of investor money is an absolute necessity to pull it off. My instinct says they should be able to ship the first version in 3 months.

[paulca]

Yea, but if you do that the company can't afford to carry all the dead weight and those people have salaries and often climb the ladder faster.

Start ups is where that is made or broken.

Mature companies, whether it's IT, software or branding are always slow in a mass of ceremony and bureaucracy.

Trying ordering a new printer in the NHS and see how long it takes.

The model I liked from my career was the properly fronted and interfaced dev team.  We didn't attented stakeholder meetings.  We recieved all work and communications from the scrum master and tech lead.  Yet you sat in the same room and you heard the calls where they defended you constantly.

That emerged in a very rare opportunity in a very large company where the department head (an exe developer and a good one), got enough traction to say, "Look.  Leave it to the team, leave them alone, let them do it their way and lets see what happens."

We closed the project successfully in 6 months.  Thus on deadline and on budget without dropping a feature.