Why Building Apps the Wrong Way Can Be the Right Way

It may seem like it, but no engineer writes &quot;right&quot; code on the first try. They get it working, then they iterate, cleaning it up to make it &quot;right&quot;.<p>Experience teaches us where to start, where to think ahead a little, and how to structure code such that it can be refactored in the future.<p>Writing code the &quot;right way&quot; means 1) getting something working 2)taking what you&#x27;ve learned and refactoring and&#x2F;or.<p>If you care about maintaining a chunk of code for 6 months, or a year, you&#x27;ll quickly learn to refactor. If you are prototyping, right likely isn&#x27;t a priority to begin with.

If you build it they might come. If you don&#x27;t build it they can&#x27;t come. Therefore you must build it for them to come. Therefore the most important thing you do to make them come, is to build it by any means necessary.<p>Them of course means customers.

Most of the code I write at work is just automating processes and I usually do it piecemeal until managing it all gets too unwieldy then I refactor and simplify. I&#x27;m not exactly building one to throw away, but I&#x27;m using a lot of essentially placeholder code that I know I&#x27;m going to replace with a more coherent system once I see the pieces working together. Sometimes the quick and dirty stuff is good enough and I never need to touch it again, though.

Brooks said it best: &quot;Build one to throw away&quot;

&gt; Twenty minutes of debugging later, it turns out I’d forgotten to call .show() after creating a Toast.<p>It amazes me that people still think that strong typing isn&#x27;t useful.