Making crap to hit deadline

Of course this works, and of course the other part (and then cleaning up the mess afterwards) doesn’t. If you have to clean things up afterwards, the only way is to sacrifice your own spare time.

I’ve never been allowed to do “code improvements” after feature perceivably works. “It works, go on with the next task! Can’t you see how far behind schedule are we?”. No one builds the perfect thing first time, and sadly I often find that my newborn code is not of high enough quality to be sufficiently maintainable. This is reality. I can write good code, but only when I spend some iterations improving it. I cannot make it good enough first time. Yes, it may be possible to do this, but only when working on familiar problem nth time. For instance good OO skills may do half the job, but what remains, the problem domain, and I don’t see a way to model it perfectly the first time.

I don’t want to work on the same damn problem for the nth time…

Semi-Complex code

The codebase I am currently working on has some parts having as I call it, semi-complex logic. It has good names most of times, it adheres to reasonable coding standard, and it actually works. Well, most of time. However, it has copy-paste-alike constructs all around. There are lots of dead / redundant code. And each class has just too many responsibilities. This looks like a kind of code our developers seem to be happy with. Must be because they are most productive producing it. I too seem to be most productive when producing highly-entangled, low level of abstraction code. But in a few past years I settled to opinion that long-term qualities of code matter the most, event for small applications. And hence, nowadays I tend to write code I am not most productive writing, taking time to manage dependencies, eliminate duplication, extract methods. I’m still not that good at it, and of course no one appreciates it. But still I try…

What troubles me about this semi-complex code, is that it carries lots traits of bad code. Most notably, out-of-place dependencies. It suffices to have one wrong dependency, and soon inconveniences start to emerge. Like, having executable module link to seemingly unrelated one. And everyone seems to be OK with it, taking this as necessary evil. Another trouble point is that the code itself is easy to read, but it doesn’t mean you understand how it is working. Because responsibilities are not clearly separated, and some side-effects take place occasionally.

Software, Soft

I’m against attempts to bring discipline to SE akin to other engineering disciplines. Like the SEMAT movement. Software is just so much softer than materials of other engineering disciplines, that it allows for so much more freedom and agility (as indicated by success of agile). Attempts to prevent failures also prevent successes, and leads to stagnation. I don’t mind if someone creates those restrictions for themselves, but just hate when they try imposing such huge restrictions on me. Yes, it’s true in software it’s so easy to shoot yourself in the foot, and such disciplines can help to prevent that from happening. You may say this is an “Adult” approach, as opposed to “childish”. But there is just so much potential in Software, even child cannot embrace it, not speaking about adult. Bad practices will simply go away because they are not working, and there is no need to present me with The One And Only set of right practices, beyond which I should not be looking further. Software principles/guidelines/methodologies/etc should be soft.