On the way to perfect computing

Yeah, sometimes the code just flies out under our fingers, you don’t think about typing, you don’t think about switching between editors, IDE panels and browsers, you do all of this automatically, all you can think is your idea and its implementation. Done, for a couple of hours. In these cases you don’t need deep debugging cycles, you already thought over every detail, like a painter creating beautiful picture,mirroring it from your mind directly to keyboard…

Unfortunately, as it usually goes, our coding life is not so appealing. Sometimes you do nothing but just update your Eclipse, you look for new features and bugfixes, but surprisingly some stupid plug-in consumes your CPU cycles and prevent Eclipse from breathing freely.
Sometimes it’s a set of other non-technical factors that makes your coding muse leave…

But from time to time some annoying bug appears assigned to you, and you realize that you don’t want to fix it at all. By no means I’m telling that you don’t like fixing bugs at all. Bugs are part of our life, accept it. It’s a good thing to do – fix them. But I would like to touch those bugs that are injected because of architecture. Somewhere deep inside you understand that global factors caused these bugs.

Looking around you will find a lot of books on software design. They talk a lot about software quality and how software processes are connected to it. They all tell you not-todo-things. Clear set of things you should avoid to do. Why? Because it’s simple to describe someone’s failure and try to guess origins. There is plenty of examples in the field already. They’ve got a lot todo – put it on paper.
However, I guess that a couple of guys on our planet still know how to write software in a right way, but usually they don’t like writing books

Each software type is special, it requires a set of specific patterns and approaches. You need to combine a lot of ingredients in order to get perfect soup. In case of software, you should be ready to make another soup at any worth-while point. Moreover, architecture should be self-explanatory, it shouldn’t take a lot of developer’s efforts to decide where he should put new piece of functionality. It’s a function of a lot of params.
So, almost everyone faces a moment when there are no uncovered challenges left in the projects he is working on. You know technologies, you know your domain area, sometimes only introducing new frameworks makes you smile.

So, the truth is, that your next challenge should be re-writing you project in that way, that it will be easy to fix bugs and it will be difficult to discover difficult-to-fix architectural bugs, there will be a minimal of “chain bugs” – when changes in one places screw up others. Your architecture will protect you. Like technology makes impossible for drunk tram driver to hurt people walking around, due to rails.

And in order to solve this puzzle, you need to question yourself each time you are looking at newly discovered bug – “What’s the origin of this?”