The Ecology of Great Tech
No-one really likes engineering war stories, but this one's relevant because there's a moral to it. I've talked before about defining technical debt as technical decisions that provide immediate value, but with long-term negative impact if they aren't cleaned up.
Software is so suffuse with money that it can be hard not to think in the "product" mindset. Sometimes the product is just for yourself and it's the journey of making something.
CQRS is often associated with microservices and event-sourcing, but it stands alone as an excellent alternative to MVC design.
Part 1 of 2
An overlooked aspect of accessibility.
One thing I like to ask in diligence is how people in engineering and product judge the value of third-party software purchases. Sometimes these are buy vs. build decisions, but in others an engineer sees an opportunity to save X hours of time per engineer per month for $Y
The Buffalo River, nestled in the Boston Mountains of Arkansas, is one of the best floats in the country. It's so iconic that it's been protected as a National River, the first of its kind. Clear water, tinting to green-blue in the depths. White limestone
There's a problem I see more and more in companies, where Product is thrust into the role of "supervising" Engineering. This is not actually their demesne and will cause friction in the end. Engineering is accountable for development, testing, deployment, and reliability. Product is accountable for
I talk often about how modeling data should be done later in the process. If you start a new project with a models.py or com.mycompany.models.* or models/*.rb then you're putting the cart before the horse, and you're going to model data badly
In my previous article, Your SaaS's most important trait is Evolvability I talk about the need to define fitness functions that ladder up to core company metrics like NPS, CSAT, GRR, and COGS. Just today I had a great followup where a connection on LinkedIn ask me for
Avoid, avoid, avoid starting a project by modeling your data in an ORM. Why? Because the temptation in data modeling is to model the "thing" perfectly instead of prioritizing your model by utility within your domain. I have seen countless projects die a slow unsatisfying death because their
In the world of commercial SaaS, your technology is always on a trajectory to become generic . Competition catches up. Broader trends change the way software is meant to look, feel, and be used. The longer your product stays static the less it stands out. What this means for your technology
So by now you know I'm a software guy. But what makes me an ecosystem guy? Back in 2020 the pandemic closed down our physical office and made it possible to make my partner's and my long-time dream of living in the mountains a reality.
Communicating technical debt to people other than engineers is essential to getting work on that debt prioritized and valued alongside bugs and product roadmap work, and it’s not easy at all. One key quality distinguishing a good engineering leader from a great one is the ability to bring
I've run the tech side of the M&A playbook now I think 10 times. I want to talk to fellow tech executives who are looking at acquiring a company about tech diligence and what it's for. In 2021 we bought a 30 acre hobby