Javaddicts

Maybe I was too harsh last time or too emotional. Of course this is part of our jobs. From the project view I guess as a startup you can live like this for a while. Especially if you dont have too much code to write, or customers who pay a hell of a lot of money for your product. But if the project comes into the years, some developers passed by, you have some code nobody has an glue about, had some dirty hacks to make without cleaning up afterwards the chaos starts growing and the troubles begin. Then you need some rules.
I have seen too many freelancers who resignated due to these cirumstances in some projects. They say, oh well, its their problem, if I get my money everything is ok. With this nothing gets better. So I started writing a paper, but how to tell them what they dont wanna know?

* Stay positive but certain. Saying things in a positive way helps them to understand you. Tell them what they gain with the changes and not what desaster is going to happen or thats all bullshit what they are doing. Tell them about the increasing motivation, that they are going to be more productive.
* Explain them whats wrong and how it could be solved. Have at least one chapter where you show some starting points. As an example if they dont have any tests, how they could start writing tests, at the best show some examples.
* Stay honest, dont promise things you cannot hold. If all goes well your paper will be an important one. They will take every word very serious.
* Though the managment decides stay connected with the team. Not necessarily with all, but if it comes to changes you need at least some of them.
* Consider the consequences. It happend to me one time that after the CEO read our paper the project leader and team leader had been suspended because their reports draw a wrong picture about the project (and we could proof our statements). So insist its nobodys fault and they have to look ahead and not behind. If personal consequences are not avoidable its at least not your fault. You just told the truth.

Something I realized over the last days: Small companies with junior teams don’t finish projects on time, because noone knows how to do it (see this post), while big companies don’t finish projects on time because everyone thinks he knows how to do it right and the process stalls over useless discussions and over-regulations.

What’s the solution? Common sense and a good team, I reckon. Both can in some way shield you from the environment that wants to slow you down, be it intended or not.