I agree with you disagreeing. The article really blurs the line between mere code formatting, which can be completely automated to adhere to some guidelines, c

I agree with you disagreeing. The article really blurs the line between mere code formatting, which can be completely automated to adhere to some guidelines, coding paradigms and software design/architecture. I'd argue that, for a product that needs to extendible and maintainable, well thought-out software design is at least as important as working code. It takes a bit more planning up front, specifying the system to be developed in terms of well-understandable and well-documented patterns but this time (and hence money) is not lost. It pays back double during both the initial implementation and maintenance. A well thought out software design takes a lot of tasks off the people who go to implement it. It clearly specifies which parts are to interact and how they can be expected to behave. Therefore it fosters modularity and independent development of modules, which speeds things up and makes maintenance and extending the product easier. And that is what we really want after all. We want to get code and therefore products out quickly, we want to avoid bugs, we want to make sense of the whole thing after a couple of months have passed in order to implement NewFeatureX™. There are numerous approaches to this. Object-orientation is just one way to do it and sometimes it's not the best way. After all, all these paradigms and schools of thought are but tools to get the job done and as always, it's a good idea to chose the right tool for the job. The other thing is actual code "beauty" (however one may define it), which ultimately means readabilty. This is important too but it highly depends on what people are used to. That's why there're often coding standards for a given project or a company. Everybody gets used to them and no one needs to rethink when reviewing the code of other developers. There's no better or worse there. The only thing of importance is that it shouldn't be possible to pinpoint who exactly wrote a certain piece of code by just looking at it. If it looks like you wrote it, you'll understand it that much easier because it takes all the burden of messing with strange-looking syntax away. The "just-get-it-done" approach to software engineering just doesn't work for projects of a certain size. That's probably why we call it "engineering" in the first place.