Good software trumps elaborate code. And unfortunately, you can’t usually have both. The real world has deadlines and ship dates. It’s a game of pick two:
- Ship on time
- Ship with elaborate code
- Ship with a fantastic product
Almost always, you should pick the first and the last when you’re building software applications for users (if you’re building API’s or open source libraries for other developers, then it’s a different story).
Too often I have seen developers, when struck with a brilliant idea, no matter how small, plunk away at building an elaborate object-oriented API for the idea. They construct a slew of objects, the objects interact with each other, and they have public facing methods to make calling them simple, even though the only person that'll likely ever need to use it is themselves. That’s really great. They just wasted a lot of time. During this time, their momentum for this brilliant idea has totally deflated, and they have spent days of work where only hours are required.
Instead of focusing on what many think of as 'good code', flesh out your brilliant idea as a fantastic product. Focus on developing it with only what’s necessary to make your idea work well. That’s not to say make a shoddy job of it, instead do without things you don’t necessarily need. Do you really need a full objet-oriented API right now? Do you really need to make a dozen interwoven classes, when it’s possible just a hundred or so lines in one class will do fine? Can you do all the same error checking and unit tests in a much smaller code base?
If you can, you will build a much more maintainable piece of software. Instead of 3,000 lines of code, you have 1,000. Instead of a ton of object dependencies where one change means having to find the references to it in all of your objects, you simply change what needs to be changed, knowing there’s no extra dependencies in your code for the sake of having elaborate code.
I am working on a software project where I came up with an idea for an interpreter that would translate the public GIS data in to our own specification that our applications expect. Instead of importing and running tons of our own data, we could expand the reach of our applications to a dozen neighboring counties by the time I finished writing the translator. I sat down for 3 hours and wrote 100 lines of code, and was finished. It was all in one class, and it worked beautifully. The product was rock-solid.
One of my co-workers, upon seeing no objects and only 100 lines of code, declared, “Oh this is a prototype - you still need to build the feed object API , but that’s OK, I can just rewrite some parts of the current one in no time.â€
Four days later he was finished. He had spent time tackling all of these problems that came up. Every time there was a problem and he needed to make a change, that change had to be reflected in multiple files. And in the end, the product did the same exact thing. The product was no more stable than my 100-line version, it was an absolute bear to maintain, and it wasted a lot of time and momentum.
Good code is not elaborate code. Good code is what makes a good product. Good code for a simple plugin can be 100 lines. Just because you wrote only 100 lines of code in three hours doesn’t make you a lazy prototyper, that makes you a smart developer. If you sit back a look at all your code and say “beautiful,†you’ve done it wrong. If you sit back and look at the beautifully running product, you’ve got it right, and you’ve probably finished a couple of days before your co-workers, with the same product. So go and move on to the next thing, you know you want to.
Source:http://blog.alexobenauer.com/stop-writing-good-code-start-writing-good-sof
