Testing
-
🛤️ When building connected products, two things have to go right
The first is architecture, decided partly up front: network topology, the protocol between processors, how function is partitioned across boards, real-time constraints, the data model, how firmware gets updated in the field, and how operati…
-
The Ability to Improve
(while this article contains many general ideas, it is written from the perspective of product development.) If you don’t continually improve, you soon lose the ability to do so … This thought came after an associate described a company tha…
-
🏗️ Good architecture
We may think of “good architecture” as getting it right up front. We certainly want to do as much of that as we can, but perhaps a more important part of “good architecture” is that it enables innovation loops. Good architecture makes loops…
-
🛩️ Why did the Wright Brothers succeed?
While Samuel Langley had $100,000 (equivalent to $3.5 million today) in funding, a team of engineers, and Washington connections, the Wrights were bicycle mechanics from Dayton, Ohio with a fraction of those resources. Langley’s approach wa…
-
🟢 What is in the Big Green Button?
As previously stated, the Big Green Button enables teams to quickly and confidently release. But what is the Big Green Button? Several things come to mind: Automation that translates code/design/docs/models into assets others can use. Auto…
-
🔗 What defines reliability?
Reliability is a common concern - this thing is critical - it needs to work! Many things affect the reliability of a system: Bugs in software we write Bugs in 3rd party components (OSS, etc.) Hardware failures Edge condition failures (thin…
-
🔍 It is often more work to review something than to do it
As an experienced person, I am sometimes called on to review something. This can be a frustrating, seemingly hopeless task. With one developer, I commented that he could write code faster than I could review it. While there are some issues …
-
🎯 Standards for internal vs external releases
It is natural to think of internal releases as “low stakes” - if it crashes and burns, no big deal. It’s just an experiment, right? Near production release, we’ll toss it over the wall to QA/Manufacturing and find all the issues. This is pa…
-
🤝 A release is what unifies Engineering and Business
Some feedback on yesterday’s post (What is a release): What specifically flows into the two points? Value? Effort? Perhaps a better way to phrase this is these are the two points of focus that unify the development team with the rest of t…
-
🔍 AI coding requires better inputs and robust verification
Some great feedback on the previous post (Impressive is not always effective): “I agree. It would be interesting, however, to compare the progression of AI code generation with that of compilers - were there star assembly-code engineers sa…
-
🔄 Platform Thinking is a habit
Platform Thinking in the context of product development has many parallels to effective habits in personal life. With personal exercise, healthy eating, getting enough sleep, and reading good books - these are difficult to start, but easy o…
-
🎯 Who is Platform Thinking for?
Platform Thinking is for anyone who wants to take the friction out of creating, publishing, testing, integrating, and deploying products. The result? Value. Quality. Timeliness.
-
📝 DDPD - 🧪 TDPD - 🚀 RDPD
We have been discussing document, test, and release-driven development (doing these things first before implementing features). This ensures the product: Meets the customer’s needs (DDPD). Is quality (TDPD). Can be modified any time and re…
-
🧪 TDPD - Test Driven Product Development
We’re familiar with TDD (test-driven development) in the software world. Basically the idea is to create unit tests before implementing a feature. What if we extend this to systems, hardware, and even mechanical? Write end-to-end system te…
-
💡 Reflections from AI-coding a 10,000 line app
Lessons from AI-coding a 10,000 line app BRun is getting usable. Claude Code wrote almost all of it using Doc-driven development (manually write/update the docs, and have Claude write the code). Some thoughts: Claude is fast – there is no …
-
😊 Other ways to align the happy path
Yesterday, we discussed aligning the happy path in code. Are there other ways to align the “happy path”? (The happy path is the desired path where things are functioning as expected.) Some thoughts: Focus on your productive people - as a ma…
-
🔄 Flipping the playbook for AI coding
A lot of focus these days is on “good AI prompts.” Some of the best prompts may be documentation and tests. Write your CHANGELOG.md entries first, then update the documentation, then write the tests, then tell the AI to update the code to m…
-
➡️ Frontload the boring stuff
Some examples: Think about and write tests before implementing a new software feature. Automate deployment of a new service before developing it. Create eCAD libraries before doing the schematic/layout work. Document the architecture befor…
-
🌿 A natural way to get more testing/automation
One thing I’ve noticed is when I release more frequently, I tend to automate. If releases only happen once every year, it is easy to neglect automation, CI/CD, etc. Automated tests are not needed as it is just quicker to manually test every…
-
✅ Guarantees
Sometimes we want guarantees: Are you sure this will work? Can we lock this down to a rock-solid stable release? Is it fully tested? Will this vendor be able to provide this part forever? Do we have all the features the product will ever n…