I pity the fool who did test first development on applications with less than 10 functionalities for instance.
Even as a manager it's the gaffatape programmers who end up saving the day rather than the best practices.
Obviously I won't advocate against following best practices. It's just that people never seem to agree on what they are, making continuity rather hard to pull off over longer periods of time.
The gaffa tape approach encourages further such poorly thought out modifications when the stacks of gaffa become a death trap that you either have to Indiana Jones your way through with a gun, bags of sand and a bullwhip or tear down and rewrite.
But since you can make pretty much any development strategy work for about 18 months, by the time the consequences are felt either those people are gone or nobody still there can paint a clear cause and effect story.
The key feature of gaffatape programming is that it gets shit done, to make sure you're still around to do a 3.0 release.
The key downside of gaffatape is that it requires better talent, because your programmers need to know how to hack it in a way that won't ruin your codebase.
Yes, the other ones are to busy fixing the gaffatape programmers' code to ensure the last day will stay saved.
The thing about gaffatape programmers is that they learn how to do things that won't end up biting us in the ass later because they are thinking about what, why, and, how they are doing things by default, rather than following orders. Well some of them learn, the rest have short careers.
I mean, as I said, I don't advocate against best practices. If you want to gaffatapetape, you need to know best practices, because you need to understand why you are not following them.
Or the fact that it looks 90% done, so the idea that you did it in 2 weeks means you are just days away from completion, right?
Sometimes the reasons for not hacking stuff together can be quite political, both for internal projects and for consultant/client relationships.
This reminds me of an automated licensing call I was putting together once. The company owner wanted me to insert some verbiage into the notes field, only the web api didn't support the notes field (but you could do it by logging in and manually updating).
I had started to plan on how I was going to do this via a headless browser. I start asking the owner questions to clarify things and he says "just email XXX with the information and she'll manually log into the site and copy/paste the notes you put in the email".
And I thought... you know what? that's really fucking smart, I'm way overthinking this. They're going to get 4 or 5 license activations/month MAYBE and this approach is a whole hell of a lot more simple and robust than pulling in a headless browser to simulate it.
I then had to stop and think about why I hadn't considered that approach before.
I guess the point is that I agree with you wholeheartedly. Not only in terms of simply cost, but in terms of complexity, stability, and ambiguity as well.
The ideal, normalized schema would be slow and awkward for manual insertions on a daily basis, which I felt would deter me and hence undermine the project.
The not-quite-normalized version would be much quicker and more intuitive for me to keep up-to-date, so I talked myself into it.
In the future I can always write a stored proc to process the less-normalized data into idealized tables, and use the original tables solely for importing the data.
Despite that reassurance it was remarkably difficult to accept that doing the 'wrong thing' programmatically was the 'right thing' in a project scope.
Many of the current databases like Postgresql let you create views. And the performance even on a smaller machine is quite good. So if you stick to a normalized schema and build views, it will pay dividends later on.
I garden, and before that I tried and failed at bonsai for quite some time. With landscaping it's good to have a five year plan, because everything keeps changing when you're not looking, and if you tried to do everything you wanted all at once you'd hurt yourself and/or kill the plant(s).
I also played Go for a long while, and I found parallels with the philosophies in refactoring. One of the big things in Go is that there are always fifteen things you could be doing but some have contingencies, and among the others you can't win unless you prioritize these options better than the other guy. You know what moves you will make, and when the time is right you will make the move, and the next and the next almost without thinking, because there are patterns just like in software. But right now this other move has more upside so you are doing that instead.
It's a concept I try to keep in mind, but am never sure I am "doing it right".
Where people get into trouble is when they have a short problem space horizon and don't have a decent feel for the trade-offs being made and a reasonable understanding of how the "wrong solution" is related to the "right solution". That can lead to the creation of a hack-y, fragile and unchangeable system that can really limit progress in the future.
If you know you're cutting corners, the ability to change in the future should be the priority. It usually means that you need to consider how the "perfect" solution would look like, so you know where the possible refinements will come to play.
There is a point within a company, where you have to switch from Minimum Viable Product to Minimum Valuable Product and try and live by the motto "Write your way out of a job".
Not sure where I am going with this, but I think the OP is right. We overthink things sometimes.
Cool project though
"""
We started with a completely unscalable solution, which enabled us to validate the need. We then evolved it, step by step, to make it support more and more users. On the way, we learned not only about our users, but also discovered what the technology requirements were. We can only speculate what the outcome of the project would have been if we hadn’t let ourselves find a “quick and dirty” solution.
"""
The longer the future of the project, the more likely that tech debt will have to be repaid. And the more closely you're involved with it, the more likely it's you who'll be paying it.
For instance getting a new environment setup inside a company that is a big Azure customer. There are forms, reviews, cost centers, and more reviews. Even to get a QA environment. I have access to a subscription, and more than once I've just set things up for people.
We're talking potentially weeks of time lost just to start working.
Not to mention the seemingly severe lack of willingness to prototype within an organization these days.
