Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...

Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...

Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
>400 subscribers
>400 subscribers
Share Dialog
Share Dialog
Another key Kaizen technique is the customization of tools or even the creation of entirely custom tools. In one of the early posts I wrote about how a Japanese automotive supplier was able to switch parts in injection molding in minutes whereas a similar German supplier needed almost 12 hours. The basic setup they were using was quite similar, but the Japanese supplier had made extensive modifications to the basic injection molding machine. For instance, the die (mold) has to have a certain temperature. The German supplier moved the die over to the machine cold and then had to heat it inside the machine. The Japanese supplier had created a custom tool to pre-heat the die (mold) so that it could be switched into the machine at operating temperature.
This is critical in software development also. There are great tools out there, but none of them will ever give you an optimized process for what you are trying to accomplish. Customization of tools is therefore critical. And this is not a one-off exercise but rather a question of continuously making small improvements. Take version control for example. How do you merge branches? How do you deploy from the repository? These are areas where huge quality improvements can be achieved through customization. For instance, any manual step in the deployment process is a step that introduces the possibility of operator error. Given that almost everyone’s repository layout and deployment infrastructure are different, no tool can automate this out of the box.
In some cases it may even pay off to develop a custom tool from scratch. This tends to be the case when you have identified an improvement opportunity that is particular to your process or business and has a small scope. It’s true that you could sometimes customize a larger tool to meet that need, but that often comes at the cost of having to spend time on figuring out how to get rid of or hide the features of the larger tool that you don’t need. Instead, creating a custom tool in a scripting language can be a much better fit.
I have become so convinced of the importance of this Kaizen technique, that I spend time on this whenever I interview folks for development jobs or meet with development teams from our portfolio companies.
![Reblog this post [with Zemanta]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/http://img.zemanta.com/reblog_e.png?x-id=e92beb23-1814-421c-95a8-ad818f270a30)
Another key Kaizen technique is the customization of tools or even the creation of entirely custom tools. In one of the early posts I wrote about how a Japanese automotive supplier was able to switch parts in injection molding in minutes whereas a similar German supplier needed almost 12 hours. The basic setup they were using was quite similar, but the Japanese supplier had made extensive modifications to the basic injection molding machine. For instance, the die (mold) has to have a certain temperature. The German supplier moved the die over to the machine cold and then had to heat it inside the machine. The Japanese supplier had created a custom tool to pre-heat the die (mold) so that it could be switched into the machine at operating temperature.
This is critical in software development also. There are great tools out there, but none of them will ever give you an optimized process for what you are trying to accomplish. Customization of tools is therefore critical. And this is not a one-off exercise but rather a question of continuously making small improvements. Take version control for example. How do you merge branches? How do you deploy from the repository? These are areas where huge quality improvements can be achieved through customization. For instance, any manual step in the deployment process is a step that introduces the possibility of operator error. Given that almost everyone’s repository layout and deployment infrastructure are different, no tool can automate this out of the box.
In some cases it may even pay off to develop a custom tool from scratch. This tends to be the case when you have identified an improvement opportunity that is particular to your process or business and has a small scope. It’s true that you could sometimes customize a larger tool to meet that need, but that often comes at the cost of having to spend time on figuring out how to get rid of or hide the features of the larger tool that you don’t need. Instead, creating a custom tool in a scripting language can be a much better fit.
I have become so convinced of the importance of this Kaizen technique, that I spend time on this whenever I interview folks for development jobs or meet with development teams from our portfolio companies.
![Reblog this post [with Zemanta]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/http://img.zemanta.com/reblog_e.png?x-id=e92beb23-1814-421c-95a8-ad818f270a30)
No comments yet