religious programming

[deadalnix]

Le 11/10/2011 11:57, Gor Gyolchanyan a écrit :
> I can't keep it in any more, I have to share.
>
> The code is unimaginably bloated, flooded with thousands of tiny
> redundant classes, each of which do a primitive task, which doesn't
> need to be a class at all.

Well, you'll have to admit that you are a religious yourself. I 
currently facing problems with that state of mind, trying to put back a 
project on track.

This lread to very difficult code to maintain and make evolve. The key 
point here is separation of concerns. Even if you have to write a 
function with 2 lines of payload, it will pay in maintenance, testing , 
debug and future evolutions.

That said, I face often the other argument : this 
class/function/whatever is too big. Well if the function contains a damn 
procedure that the program must follow step by step, a long function is 
definitvely the way. Separation of concern as usual.

This doesn't means you software will be bloated. You can use 
metaprogramming to assemble all thoses parts at compile time.

I'm also sometime facing religious behaviour of mine. We all do that. 
The key is to be ready to open up when a logical argument is proposed. 
This is the way you evolve.

Back on the subject, company policies are often made by so called senior 
programmers, that did the same mistakes again and again and again for 
years and enforce them in the company throw policies. This is a fact, 
most people hate change, and will do whatever they can to avoid it (if 
you are interested on the topic, this is broadly studied by 
psychologists). You'll have a natural tendancy to do that yourself, it 
is natural. Fight it every day to be a better programmer :D

The 100% OOP iritate me too (and a part of my job is in java) but it has 
the advantage to avoid people to learn new concept. Sadly, this is what 
they want. And this is sometime what is better for the company, because 
you don't want to work against your employee. They will be demotivated 
and unproductive, but worse, reluctant to do good quality work.

Back to company, I did myself showed to management that I was very 
productive and did quality code (less bugs, easier to evolve to includ 
enew functions). This is important to show that by RESULTS. When you 
have data and facts, you can push good practices in the company.

Now we got better working conditions (better hardware, better workspace, 
etc . . .) and are way more exigent on new employee capacities 
(especially thoses who worked with non mainstream technologies like D 
obviously, but also haskell, erlang, or basically anything that show 
curiosity and eager to learn new stuff and get better). And this is working.

Remembrer : if you can't change the place, just move. IT gives a lot of 
opportunities. By many of them will be in similar conditions than your 
current position. You usually have to change the company or be very 
lucky to find one which already know what software is about.