FCHouse A blog about our lives, our passions, our photos

>(and all the project management issues in general) should be used carefully …
That is where any project relies on.

>you are simply asking for a “Time Mortgage“… you will be asked to pay a LOT of interests!
It is like selling your soul to the devil

good job!

Posted by frank on 24 August 2006 @ 10am

It is like selling your soul to the devil

Mumble… When you take shortcuts, duplicating code, forgetting bugs and covering small mistakes just to be “fast” you forget a Very Important thing: You will have to work again on the code you are writing.
…Sometimes they Returns…
…and when they do you will try a lot of pain!

:D

Posted by Carlo on 24 August 2006 @ 10am

Yes Carlo.

But you’re not thinking that many in Italy have found a wonderful solution for that.
It’s called ‘hit and run’ : you do as fast as you can all the job in one run and then, when the customer is satisfied and paied the bill, you leave the position in the firm, change your e-mail address and mobile phone number and that’s it !

The nightmare will not follow you !

The idea is so good that supposed-to-be-IT-companies are acting like that …

I’m sadly joking, you know…

Posted by Stefano Grevi on 24 August 2006 @ 10am

Hi Stefano!
Unfortunately, and you sadly know it, it is not “completely” a joke!
Personally I really can’t turn my back to the works I’ve done in the past and I give support, if needed, also to my previous employer. But it’s because of me, it’s because I believe in personal honesty.

The REAL PROBLEM is that too many times the milestones are too narrow, te pressure is high and the result is a code written as fast as you can. It is the problem of quantity against quality.

Personally I believe that keeping a “little bit” of attention in the everyday work can solve 60% of these problems. I mean that if during your everyday work you take care of the “things that should never be done”, without letting them stack in a big pile of “To Be Deleted” (or “To Be Modified“) you will never forget them and you will be never required to solve them when a new project will take all your time.
But it’s a state of mind…

Posted by Carlo on 24 August 2006 @ 10am

Unfortunately I don’t fully agree with you.

As a matter of responibility the milestones for the releases should be agreed between two subjects : the customer, the contract manager and the appointed technician.

The reality is that the contract manager doesn’t inform of the project the technician ’til the last minute when the milestones have already been discussed WITHOUT THE KNOWLEDGE TO KNOW HOW MUCH TIME IT TAKES TO…

So, by the very first step, it’s also a mistake of the appointed (group of) technician not to make clear (best, is a mistake not to write this on an official document) that the evaluated times are wrong and unreal.

Sometimes I’ve found that also ‘how’ to do something was stated by a man who doesn’t know what the methods and tools let you do ‘forcing’ wrong methods and way of designing/writing/testing programs.

For this couple of reason, because also my free time is precious, I decided not to pay dire fees to correct mistakes originated by others once the job position was left.

I have in my career many programs released. The ones I produced myself or with skilled and thoughtful team managers and customers are still working (the oldest has 8 years, a 7/7days 24h/24h working application) and when I’m called about them is mainly for little maintenance.

For the others … I don’t give support for code touched by the script kids the others hired after (and also on top of or before) me. Is not my job to clean the other’s mess !
I have too much to do cleaning mine !

When I worked last couple of years my first command word was ‘refactory’, i.e. clean the ‘dirty’ code and make it readable. Of course has to be made day by day.

Posted by Stefano Grevi on 25 August 2006 @ 10am

Stefano,
sorry for the delay in the answer…

I can agree with you on the points you have written on, I was just from another point of view. I decided to remove all the problems unlinked to the simple “code writing”.
Too many times you take control of codes that are not well written (or that are simply not written in your style), but you can’t refactor everything. The time is money and nobody can tell his own boss: I need two days to complete this task and two weeks to refactor the whole project!

Sometimes you have to accept that if you have to set your hands into a dirty code you didn’t write, you have to move less things as possible.

Refactoring code is usually an unavailable option, because sometimes, for working project, the risk of messing everything up is high. This kind of risk is not an adequate solution but for the ureleased project.

IMHO, of course!

Posted by Carlo on 3 September 2006 @ 7pm

>Too many times you take control of codes that are not well written (or that are simply not written in your style)…

Right. You have to distinguish between your style and a ’standard’ set of rules that makes the written code at least understandable to everyone.

>The time is money and nobody can tell his own boss: I need two days to complete this task and two weeks to refactor the whole project!

In fact you can’t. You can’t also tell to your boss how muche it takes to complete the task because of the mess you are putting your hands on ! So I think it should be realistic to tell +30% of time more and trying to make at least readable the code (changing variables names like 5TATU5 in BillStatus, for example).
As the Master Fowler told “Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” (See this) so changing merely the variable names doesn’t take so much time and makes the code more readable.

>Sometimes you have to accept that if you have to set your hands into a dirty code you didn’t write, you have to move less things as possible.

Yes. But the dirt can be cleaned starting from simple, unharmful tasks to improve readability like in this.

>Refactoring code is usually an unavailable option, because sometimes, for working project, the risk of messing everything up is high. This kind of risk is not an adequate solution but for the ureleased project.

No. I disagree because you are right only in case when you are doing ‘major’ modification in one shot. Refactoring is not such a thing. Is not taking a big breath before doing a long apnea, but is taking little pieces and looking at them from a different perspective : Do I use in other code this method, Do I need to share conditionals between different methods, Do I need to duplicate all over the code the same code ?

For example if you use the same Select/If conditional in more than 2 subroutines / methods it’s a good idea to extract it and put in a method/subroutine itself so when you need to change it you change it once !

Put an eye on this and tell me if this makes sense : Here

Posted by Stefano Grevi on 5 September 2006 @ 9am

Hi Stefano

so changing merely the variable names doesn’t take so much time and makes the code more readable.

Changing the variables names is only a trick to improve the general readability of the code. The Real Problem is usually far from some naming issues. Yes, you can find a lot of naming issues, but usually they aren’t the big problem. Working in a Object Oriented environment and having an Object that extends another object, that extends another one and so on and in the end you aren’t able to understand the generic structure of the application (hundreds of classes). In this case we cannot speak about a simple “Refactoring“: in this case you find yourself against a Complete rewriting of the code, that is impossible.
We are talking about two different things. Refactoring a code can be an easy job (naming conventions, small function redraw and so on), but can be an impossible task. If the code you are working on is a set of interlaced objects, where if you move one of them all the others stop working, refactoring is a Nightmare.
In correct development you should have a lot of “Black Boxes“. You should be able to clean everything inside, without changing the interface. But too many times this is not the situation.

What you say is correct, but taken from a different perspective. You are thinking about a code that has been written badly. I am thinking about a code that has been THOUGHT (Designed) badly, where the OO structure lets you cry, where the interfaces are nothing more than useless codes never used for what they should be used.

Posted by Carlo on 5 September 2006 @ 9am