Doing things the wrong way to get the right result

The problem with this approach is when they say &quot;okay, we&#x27;ll have an intern do the manual keying each week and use the prototype as the finished product. Thank you, goodbye.&quot;<p>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?<p>Sometimes the reasons for not hacking stuff together can be quite political, both for internal projects and for consultant&#x2F;client relationships.

This is often good advice especially in a startup, but it&#x27;s not quite absolute. It&#x27;s worth putting a certain amount of work into maintainability. It&#x27;s worth pre-empting some classes of issues. And the further you shift into being a mature business, the more serious engineering becomes appropriate.

I always think this is very much the approach MVP (Minimum Viable Product) takes. I&#x27;ve seen this taken to the extreme in a company where the IT department where applying MVP to their internal business users creating absolute havock. Eventually Business Analysts were brought in to &#x27;force&#x27; a more beneficial approach to delivering good solutions as well as get the business talking to IT in terms that each could understand.<p>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 &quot;Write your way out of a job&quot;.<p>Not sure where I am going with this, but I think the OP is right. We overthink things sometimes.

I encountered this in a personal project in the past week.<p>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.<p>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.<p>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.<p>Despite that reassurance it was remarkably difficult to accept that doing the &#x27;wrong thing&#x27; programmatically was the &#x27;right thing&#x27; in a project scope.

I think this needs to be said to a lot of stubborn egotistical designers too. Ego in some ways is good but needs to be controlled and put aside so projects get the most effective outcome.

My first step would have been to search Amazon for a web enabled door buzzer.<p>Cool project though

In addition, once you have hack solutions that are validated by users, replacing them with more robust solutions is extremely satisfying.

Being able to redefine the problem to get at a &quot;quick and dirty&quot; solution is absolutely a useful skill. What I think gets glossed over in the fine article and in some of the other comments, is that this is really only a <i>good</i> approach when one can also see the full solution as well and understands how to evolve past the &quot;mechanical finger&quot; if it becomes necessary to refine the system.<p>Where people get into trouble is when they have a short problem space horizon and don&#x27;t have a decent feel for the trade-offs being made and a reasonable understanding of how the &quot;wrong solution&quot; is related to the &quot;right solution&quot;. That can lead to the creation of a hack-y, fragile and <i>unchangeable</i> system that can really limit progress in the future.

Perhaps I am misunderstanding the discussion and do not see the &quot;wrong&quot; way: it seems that this consistent, incremental improvement is the &quot;right way&quot; to get to the the &quot;right result&quot;. Isn&#x27;t that very much a tenet of a whatever one may want to call a &quot;lean start-up&quot;<p>&quot;&quot;&quot;<p>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.<p>&quot;&quot;&quot;

I can&#x27;t. My first job out of college was extremely toxic. It was the other developers&#x27; job to completely trash anyone else&#x27;s code. It was sport to them. Now, even several companies later, I have anxiety going into a code review.

This idea is basically all about the future. If you don&#x27;t have to worry about the future whatsoever, or have no business worrying about it (e.g. you&#x27;re in a startup that might die in 6 months), by all means hack it together, get as far as you can, and &quot;borrow&quot; as much technical debt as you can rack up.<p>The longer the future of the project, the more likely that tech debt will have to be repaid. And the more closely you&#x27;re involved with it, the more likely it&#x27;s you who&#x27;ll be paying it.

It may not be absolute advice, but certainly applicable in many companies.<p>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&#x27;ve just set things up for people.<p>We&#x27;re talking potentially weeks of time lost just to start working.<p>Not to mention the seemingly severe lack of willingness to prototype within an organization these days.

Thanks for including multi-megabyte pointless animated GIF. :|

The coolest thing about ignoring trends is that most of them go away again.<p>I pity the fool who did test first development on applications with less than 10 functionalities for instance.<p>Even as a manager it&#x27;s the gaffatape programmers who end up saving the day rather than the best practices.<p>Obviously I won&#x27;t advocate against following best practices. It&#x27;s just that people never seem to agree on what they are, making continuity rather hard to pull off over longer periods of time.