3 ms·

That’s really interesting. Do you by chance have a write up or example of how this is done? I’d like to try this too.

keehun 7y ago
You remind me this could be a decent idea for a short blog post. In brief though, let's say you're implementing network filtering (inspired by today's LittleSnitch post). Before writing any code, I would: - Figure out what actual business case there is behind it and what the management/customer/etc is actually looking for. Maybe feature XYZ isn't the right long/short-term solution for what they want. People give Steve Jobs a lot of flack for "you're holding it wrong", but he was right in the sense that the customer doesn't always know what they want/need, let alone know what's even possible. - Once the feature is what is required, figure out what's the right fit for the feature within the current architecture with short/medium/long-term goals in view. Maybe it's actually better to hack something in quickly and commit to revisit in 1 week than spend a month doing it right and lose users. - Then figure out if the APIs actually exist. Some APIs you need simply don't exist. For example, in order to filter network traffic on MacOS, you needed to write a kernel extension until macOS Catalina. If your architecture/business doesn't have room for kernel extensions, then those APIs are out of reach. (Maybe Apple didn't bless your request to code sign kexts. Maybe you have no-one on your team with kernel experience. Maybe your customers are non-admin users on their Macs that can't load kexts.) During this phase, I might write some quick & dirty PoC code later in the process to exercise all the necessary APIs and make sure those actually do what they promise to do within my constraints. Once you have the business requirements, stakeholders aligned, and PoC that exercises all the APIs which demonstrate your feature's needs, writing the actual code is a breeze. Especially once you get pretty good at this, transforming the PoC code into one that stands the test of time in your product gets easier and easier. You may ask "wait, writing the PoC code is exactly what you claimed you didn't do!". You've got a point, except in this case, whenever I write PoC code, I write it as a standalone "proving grounds" program. I don't start writing code within the product's architecture. I would estimate in my PoC code, there's less than 3% that is outside of exercising the necessary APIs.

You remind me this could be a decent idea for a short blog post. In brief though, let's say you're implementing network filtering (inspired by today's LittleSnitch post). Before writing any code, I would: - Figure out what actual business case there is behind it and what the management/customer/etc is actually looking for. Maybe feature XYZ isn't the right long/short-term solution for what they want. People give Steve Jobs a lot of flack for "you're holding it wrong", but he was right in the sense that the customer doesn't always know what they want/need, let alone know what's even possible. - Once the feature is what is required, figure out what's the right fit for the feature within the current architecture with short/medium/long-term goals in view. Maybe it's actually better to hack something in quickly and commit to revisit in 1 week than spend a month doing it right and lose users. - Then figure out if the APIs actually exist. Some APIs you need simply don't exist. For example, in order to filter network traffic on MacOS, you needed to write a kernel extension until macOS Catalina. If your architecture/business doesn't have room for kernel extensions, then those APIs are out of reach. (Maybe Apple didn't bless your request to code sign kexts. Maybe you have no-one on your team with kernel experience. Maybe your customers are non-admin users on their Macs that can't load kexts.) During this phase, I might write some quick & dirty PoC code later in the process to exercise all the necessary APIs and make sure those actually do what they promise to do within my constraints. Once you have the business requirements, stakeholders aligned, and PoC that exercises all the APIs which demonstrate your feature's needs, writing the actual code is a breeze. Especially once you get pretty good at this, transforming the PoC code into one that stands the test of time in your product gets easier and easier. You may ask "wait, writing the PoC code is exactly what you claimed you didn't do!". You've got a point, except in this case, whenever I write PoC code, I write it as a standalone "proving grounds" program. I don't start writing code within the product's architecture. I would estimate in my PoC code, there's less than 3% that is outside of exercising the necessary APIs.