Great article! I think that doing some of these investigations beforehand could help understand what solution to deliver. For many problems, I find that we can take a product approach to information and insight products. I write about the ways to do that in my Substack Signal to Product: signaltoproduct.substack.com . We do have a lot of overlap and I invite you to take a look. Well done :)
One continuing benefit of starting out in the computer software business about sixty years ago is that the lessons learned in the early years continue to be essential in today's world. When I started out (think IBM 1401, DEC PDP-8, Assembler, FORTRAN II, etc.), scarcity was a constant issue. Scarcity of memory, scarcity of time available on the computer, and scarcity of people who could help in identifying problems were always a consideration.
The end product had to be constantly in mind. The code need to be as clean as possible before it was submitted for translation into machine language. Test data needed to cover as many potential defects as possible - you only had a limited amount of time to do the tests or to deal with errors that were caught by the compilers.
Over the years as technology improved, scarcity receded as an issue but the discipline that scarcity embedded retained its value. The complexity of today's software has passed the bounds of our imaginations. We now have methodologies that extol the "Ready, Fire, Aim" approach to creating software.
Even today, though, good software - software that's reliable, that's delivered on time, that does what the end user wants it to do - is being built and installed. Much (most?) of that software reflects proven, disciplined practices in design, coding and testing.
The advice in this article mirrors a lot of that discipline.
Wow, that's a great point around scarcity forcing a disciplined, intentional approach. I agree that the lack of obvious constraints in many cases causes people to not apply a particularly rigorous approach. If it doesn't work, you can just try again.
Brilliant article, I'll steal this advice and gonna reread it in the future. Thank you for sharing! ❤️
Thanks so much, glad you found it helpful and plan to reference it in the future :)
Great article! I think that doing some of these investigations beforehand could help understand what solution to deliver. For many problems, I find that we can take a product approach to information and insight products. I write about the ways to do that in my Substack Signal to Product: signaltoproduct.substack.com . We do have a lot of overlap and I invite you to take a look. Well done :)
One continuing benefit of starting out in the computer software business about sixty years ago is that the lessons learned in the early years continue to be essential in today's world. When I started out (think IBM 1401, DEC PDP-8, Assembler, FORTRAN II, etc.), scarcity was a constant issue. Scarcity of memory, scarcity of time available on the computer, and scarcity of people who could help in identifying problems were always a consideration.
The end product had to be constantly in mind. The code need to be as clean as possible before it was submitted for translation into machine language. Test data needed to cover as many potential defects as possible - you only had a limited amount of time to do the tests or to deal with errors that were caught by the compilers.
Over the years as technology improved, scarcity receded as an issue but the discipline that scarcity embedded retained its value. The complexity of today's software has passed the bounds of our imaginations. We now have methodologies that extol the "Ready, Fire, Aim" approach to creating software.
Even today, though, good software - software that's reliable, that's delivered on time, that does what the end user wants it to do - is being built and installed. Much (most?) of that software reflects proven, disciplined practices in design, coding and testing.
The advice in this article mirrors a lot of that discipline.
Wow, that's a great point around scarcity forcing a disciplined, intentional approach. I agree that the lack of obvious constraints in many cases causes people to not apply a particularly rigorous approach. If it doesn't work, you can just try again.
Thanks for sharing!
🔥🔥