It really was! I believe they were doing well, growing at a steady pace. Another part of the puzzle was that client relationships were long, over years, so if we wrote bad code it was us that would have to deal with it later. The clients were typically larger, which helped to that end.
We did take on a rushed project at one point, so there is a good comparison in that project. It shipped, but everyone was unhappy, some key people left and had to be re-hired for. It triggered a very transparent discussion roughly titled "let's figure out how to never do that again" and to that end they curated the clients more carefully, and put in some checks to see if projects are a good fit.
But I understand that is probably unique, and at previous jobs the "good enough to make money" mantra has worked out okay.
I think when your software domain is complex and rapid, it pays to have sound architecture. When it is simple, or slow to change, it doesn't matter quite as much.
We did take on a rushed project at one point, so there is a good comparison in that project. It shipped, but everyone was unhappy, some key people left and had to be re-hired for. It triggered a very transparent discussion roughly titled "let's figure out how to never do that again" and to that end they curated the clients more carefully, and put in some checks to see if projects are a good fit.
But I understand that is probably unique, and at previous jobs the "good enough to make money" mantra has worked out okay.
I think when your software domain is complex and rapid, it pays to have sound architecture. When it is simple, or slow to change, it doesn't matter quite as much.