2011 m. gruodžio 14 d., trečiadienis

30% of planing, 5% of coding, 65% of debugging

I believe this should work for programming. I think so, o course it depends on an application, but unless it's very trivial application planing is one of the biggest part of a job and at least you've done planing and coding damn well debugging will use the majority of project's time. Well the maintenance is going to tame the most of the time spent with an application, but anyways, this is not about software, but about life. Planning and "debugging" are important in both. And thinking about software applications I've seen an interesting [well interesting to me] similarity. Sure you need planing to avoid stall, but also plan doesn't often come together so, I've tried to find out why. The problem is that when you developer software application instead of trying to predict all the work it should do during it's "life", you try to create algorithms for more general situations, reactions to events, data inputs and so on, or some programmers even creates neural networks, of genetic algorithms. So program is a sort of plan for computer. So my idea is that when you are planing, creation of algorithms for situations, that is going to happen rather than situations itself is much better approach. Now, the biggest problem is how to put these ideas into practice...