A single main.py file might actually be more maintainable than a dozen files that try to hide many levels of abstraction. Certainly things need to be separated into files, but just enough to keep the project simple.
And when you're in the business of "getting shit done", most of the time delivering the feature is much more important than writing "clean code".
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"
-- Donald Knuth
Getting the code written and the app out the door in a "good enough" state is almost always the most important part. If you're a startup, it's may well be the only important part.
There is only one thing that makes "bad code" acceptable, and that is accountability. The article hints at it, the author clearly recognizes it, but it should be emphasized more.
Bad code without accountability, without a reason why the quality has been compromised, and no one to take responsibility for both the choice and the consequences of that choice, is a just crap that doesn't deserve respect.
Most bad code doesn't have the excuse that it works (it usually doesn't, at least not for long), or that shipping it was an overriding priority. Most bad code is just plain laziness or incompetence. Very few of us fall under the heading of Spolsky's mythical duct tape programmers. Most of us merely competent developers can only do one of two things: write decent code that works well, or bad code that doesn't. And the fact that we are actually able to do the former already puts us in the top 20% of people that get paid to code.
As long the majority of programmers either produce bad code or spend most of their time trying to clean up that crap (or rather, just keep it running), I don't see why people feel the need to keep writing apologies for the very few cases in which "bad" code was the best possible option.
3 comments
[ 5.1 ms ] story [ 28.1 ms ] threadAnd when you're in the business of "getting shit done", most of the time delivering the feature is much more important than writing "clean code".
Getting the code written and the app out the door in a "good enough" state is almost always the most important part. If you're a startup, it's may well be the only important part.
Bad code without accountability, without a reason why the quality has been compromised, and no one to take responsibility for both the choice and the consequences of that choice, is a just crap that doesn't deserve respect.
Most bad code doesn't have the excuse that it works (it usually doesn't, at least not for long), or that shipping it was an overriding priority. Most bad code is just plain laziness or incompetence. Very few of us fall under the heading of Spolsky's mythical duct tape programmers. Most of us merely competent developers can only do one of two things: write decent code that works well, or bad code that doesn't. And the fact that we are actually able to do the former already puts us in the top 20% of people that get paid to code.
As long the majority of programmers either produce bad code or spend most of their time trying to clean up that crap (or rather, just keep it running), I don't see why people feel the need to keep writing apologies for the very few cases in which "bad" code was the best possible option.