6 ms·
Why Building Apps the Wrong Way Can Be the Right Way
- deedubaya 11y agoIt may seem like it, but no engineer writes "right" code on the first try. They get it working, then they iterate, cleaning it up to make it "right". 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. Writing code the "right way" means 1) getting something working 2)taking what you've learned and refactoring and/or. If you care about maintaining a chunk of code for 6 months, or a year, you'll quickly learn to refactor. If you are prototyping, right likely isn't a priority to begin with.
- taneq 11y agoThe three priorities of software development: 1) Make it work (at all) 2) Make it work right 3) (If necessary) make it work fast
- pramodliv1 11y agoI heard a similar quote from Nathan Marz of Storm fame: "First make it possible, then make it beautiful, then make it fast" http://nathanmarz.com/blog/suffering-oriented-programming.html http://nathanmarz.com/blog/suffering-oriented-programming.ht...
- mobiuscog 11y agoThe three priorities of software companies: 1) Make it seem to work 2) Ship it 3) Profit ?
- g_delgado14 11y agoBeing self-taught left me with the [false] impression that the reason I don't write good code the first time around is because I never formally studied CS.
- bottled_poe 11y agoI guess that depends on whether you are developing candy crush or a aircraft guidance system. Everything starts with prototyping, but only on low-risk software will engineering procedure be discarded for the sake of 'failing quickly' or being first to market.
- jonesb6 11y agoIf you build it they might come. If you don't build it they can'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. Them of course means customers.
- saosebastiao 11y ago> Twenty minutes of debugging later, it turns out I’d forgotten to call .show() after creating a Toast. It amazes me that people still think that strong typing isn't useful.
- dragonwriter 11y ago> It amazes me that people still think that strong typing isn't useful. I've heard people argue that its not always a net benefit, but I've never heard anyone argue that it doesn't have benefits.
- mruniverse 11y agoI think I've heard this argued before. They say if it acts like a duck and walks like a duck, then they say it promotes unit tests.
- sopooneo 11y agoI have never used a strongly typed language. But it seems like it would be almost strictly superior to the php and ruby I use now. So why on earth isn't everything strongly typed? What's the downside?
- outworlder 11y agoNot many downsides, if implemented right. Problem is, most languages have very simplistic type systems, which get in your way, specially if you are trying to code a function that will operate with many different possible "types". Then they add kludges to make life bearable (see also: Generics), that will then add complexity. And are sometimes horribly implemented (see: Java's type erasure), or C++ compiler authors struggling with its template system (and users struggling to this day). Or sometimes they don't even add the kludges, making life tedious (see: Go, and endless discussions about adding generics to it) The other category of hacks is what's usually called "Reflection", or "Introspection". Any time a language designer feels necessary to add such a name for the ability to lookup things, then you know you are in a world of pain. The contortions required to by some languages to implement Ruby's 'respond_to?' method can get ridiculous. So much so, that the usual workaround is to add 'interfaces', which are a type(that does nothing useful), and so you can check the type. Or pass it around to something that will expect that over-arching type. Sometimes you just don't care about a thing's type. And, many times, the types that you should care about are not the ones that are actually specified. If I'm doing something important, I don't want the compiler to check if the type is integer, I want it to check if the type is, say, Miles, as opposed to Kilometers. That's what's important, or my costly space probe will literally crash. A language should make it easy to do so, otherwise people won't bother. Or probes will crash. Even though the program compiled. And the UML diagrams are spotless, with the factories all building the object types they were supposed to.
- PaulHoule 11y agoBrooks said it best: "Build one to throw away"
- collyw 11y agoI don't think I was ever allowed to throw away a prototype. They always end up being the production version in the end. I make an effort to make reasonably good prototypes for that reason.
- paulddraper 11y agoI might not toss it away all at once, but by the time I'm done with v2, little of the original code remains.
- empath75 11y agoMost 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'm not exactly building one to throw away, but I'm using a lot of essentially placeholder code that I know I'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.
- 91bananas 11y agoI've found it's a lot of the time that the quick and dirty is the stuff I never come back to.