Cliff Brake’s Post

How do you know if you have the ability to maintain your product? With complex systems, having all the design files and source code does not always mean a lot. Do you know how to build the source code? Do you know why the hardware is designed the way it is? Do you know how to test and verify changes? Do you regularly use these tools? The only way to know for sure if you can efficiently make a change to your product is to practice doing so. If you don’t, things soon ossify to the point where the cost and risk of any change are prohibitive. #platformthinking Is your product development stuck? Subscribe to my free "Platform Thinking" newsletter for ideas on how to efficiently utilize today's technology without getting mired in technical debt. (click my name -> Featured for link)

How do you consistently name things? There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton Plenty of opinions abound on style, naming conventions, formatting, etc. But there is one principle I try to follow when naming things -- go from general to specific. Example: - UserEmailAddress For functions, you may have a module that has multiple operations. In this case, the operation is a specific operation of a more general module. - atmtcp_v_dev_open() - atmtcp_v_dev_init() - atmtcp_v_dev_close() Even though open_atmtcp_v_dev() reads better as an English sentence. Programs can be thought of as both prose and data, and sometimes there are advantages to considering function and variable names as data. General->specific naturally organizes things. It is easy to browse variables in an editor that may list all the variables in a module. Searching/refactoring is also easier. Sometimes when dealing with two unrelated types of information, it is not obvious which is more specific. In the below example, VINST/VPEAK are measurements (type), and AX/AY/... are channels (instance). Which should go first? - VINST_AX - VINST_AY - VINST_AZ - VPEAK_AX - ... Generally, I prefer to put the "type" first, and then the "instance" -- especially if there are multiple instances. But this could probably go either way. Another way to think about this is VINST may be a map/dictionary/hash-table property of an object, and AX/AY/AZ may be keys into this map. Use nouns for variables and verbs for functions. Does this make sense? How do you name things? #platformthinking

How can we be more consistent? What does not work very well is long standards and endless code reviews where we shame people into compliance. There are better ways. We now have tools that can proactively format our code. We have linting tools that check things. Use them. Even if no one else reads our code, they help us. Write tests. Perhaps their greatest value is that they give us a new perspective on our work, which leads to consistency. We can have CI hooks that check for various things -- check out the Zephyr project if you want a good example of this. Being nudged by a CI tool to be consistent is a much better experience than being pulled over by the consistency police. Does YOUR Platform have tooling that encourages consistency? #platformthinking

Does consistency matter? If you have a single developer on a single project, then perhaps consistency does not matter too much. However, if you want to scale, either products or developers, then consistency matters. Why? So that code does not get drastically reformatted every time someone makes a change, making Git diffs impossible to review. So that any developer can easily understand and make changes in any part of the codebase. So that new products can leverage previous efforts. So that new developers can be more easily on-boarded. So that we can see patterns and simplify systems. So that our systems are tested. So that documentation can be easily found. Linux Torvalds is being lambasted for encouraging some consistency in Git commits. But if you read his actual email, the request seems quite reasonable. The Linux kernel has a well-defined coding style that all contributors are expected to follow. Have we considered the impact this emphasis on consistency has had on the Linux Kernel's success? The irony of all this is that consistency is usually done in the name of the "team" or "reuse". But if we reflect a bit, we are mostly just helping ourselves. We can read and understand our own code in 6 months. We can find stuff. We can more easily make changes and improvements. We have tools helping us. A little bit of consistency goes a long way in building YOUR Platform. https://lnkd.in/eeMRSFeX https://lnkd.in/eWgf-cWu https://lnkd.in/eTRtJbmM #platformthinking

https://lnkd.in/eXQUgkme

Isn't it risky to update your dependencies? This is a common objection I hear when building industrial systems: "We want to lock things down to a super stable/tested LTS (Long Term Support) release and then stay on that release for a long time -- it's risky to update dependencies." Is it? How often do you update your browser? Your phone? How often does Windows or MacOS force you to update your computer OS? Do you worry every time it updates? I've run Arch Linux for years and update routinely without worrying. I update to new versions of Gitea every time they come without a concern. I routinely update to the latest HEAD of Zephyr on projects during development and have rarely had a problem. The same with about every software component I use. Yes, there are safety-critical control systems that have stringent testing requirements, but we're talking about complex connected systems that are mainly concerned with moving data around. Where security is a concern. With rare exceptions, modern OSS projects get more stable with each release, and to a lesser extent with each Git commit. They have defined the laws of entropy. How? With OSS workflows, testing, continuous integration (CI), more real-world usage, more user feedback and contributions, etc. With good CI, changes don't get merged to main until they are tested pretty well. Transparency, community, and OSS workflows are powerful -- really the only practical way to build complex technology. The next time you seek the cozy cocoon of an LTS release for a dependency in YOUR Platform, think about what you might be giving up ... features, improvements, community connection, and likely also stability. #platformthinkin

Platforms are for building systems. If you are building a one-off, non-connected device, you can get by without a platform. This is why so many design-shops don't get platforms -- they are designing something then moving on to the next project. But if you are building a connected system, you have a much bigger problem to solve. You now have a distributed system, and distributed systems are hard. You are now living on the Internet with all its associated security concerns. You have a system that has the potential to do so much more than it is doing now. You have a system that has almost unlimited potential to be expanded. You (potentially) have a platform. #platformthinking

The cost of updating dependencies, or not ... As developers, we are often lazy when it comes to updating dependencies. A short-term productivity hack is to not update them. Leave our Yocto build at an old version. Never touch go.mod or package.json -- everything is working and I can keep focusing on coding features. Don't update our tools -- we don't have time. ... until things break, there is a security problem in a dependency, or we need a feature in a new version of something, etc. And then things grind to a halt. As Khem Raj recently shared (see link below), Maintenance is costlier than development, so even though development is important today, maintenance is more important -- for tomorrow. Part of YOUR Platform should be selecting technologies that can be updated regularly with little pain, and a process to do this. It is the question of paying a little bit continuously, or a lot all at once later, and the latter is often so painful that in many cases it is impractical. Investing in YOUR Platforming compounds positive gains -- neglecting technical debt compounds negative gains. #platformthinking https://lnkd.in/gkPWRc5z

New Yoe release! Yoe is a #yocto distribution that is released monthly. https://lnkd.in/eYcAxyYQ

What is the difference between YOUR Platform and other platforms? We all use other platforms -- operating systems, cloud services, middle-ware, hardware modules, etc. It is tempting when building a product to piggyback entirely on someone else's platform (AWS, .NET, one of the 100's of IoT Platforms, etc.) Society tells us -- you can't host your own service, deploy your own updates, design your own hardware, implement reliable systems, etc. But at a small/medium scale, none of these things are very hard. If you do them, you can simplify and optimize for your needs. YOUR Platform is partly the ability to leverage other platforms, but also to build your own -- where you are in control of the critical integration points. #platformthinking