Joe Ess wrote:Make a business case on how documentation and refactoring can save you time and your boss money in the long run.
Sad thing is, that some managers are so shortsighted, that even that won't work.
Some statements I heard when I complained several times about the lack of documentation, unit-tests and time to refactor:
- That's academic bullshit. In real life you don't do such stuff.
- We will do it later when we have time. But at the moment we really need this product to be shipped.
- Do it right in the first place.
- It doesn't matter how it looks like under the hood as long as the GUI is shiny.
As the others already stated you can try to become active yourself.
In my situation it was not only the documentation that was non-existing but there were a LOT of things going wrong (projects relied on the
IDE for builds (everybody had to have the same setup), no CI-Server, no nightly builds, no bugtracking-system (except you call 'mails' a bugtracking system), no dependency management, no documentation, no
unit test, no common programming style, etc.)
I first tried to write a build script which was independend from the IDE. The script had some flaws but it did its job. I also setted up a CI-Server which worked. My problem was: nobody cared.
My mistake was that I was not talking to my colleagues BEFORE I tried to change something.
Half a year later I gave it another try. I wrote a paper (roughly 8 pages) where I listed all the problems (ordered by severity) that our software development process (from my point of view) had, offered a solution (where possible with several alternatives) together with advantages and disadvantages and the expected effort. I printed this paper for every team member and asked them to read it and scheduled in the same time a meeting a week later where I wanted to discuss my paper.
That approach was much more successful because the majority of the team members were much more commited after this meeting due to the fact that they could express there own point of view and were not patronized by a single developer.
So a few tips which might work for you:
- talk with your other team members how you can improve your current situation and make sure that you are not the only one who wants to change something (if this should be the case: quit)
- try to get some time (like two hours a week) from your manager to just work on things which improve your situation (documentation, unit-test, refactoring, etc. Not for bug-fixing or new features)
- DO NOT work constantly 10 hours a day. It will break you one day and it won't be rewarded by anyone. (I came once out of a meeting which took four hours where a manager asked me afterwards what I was thinking about the results. Due to the fact that roughly 60% of the time was private chitchat (between my manager and our customer) I was a bit pissed and answered that the relevant details could have also been handled within an hour. "Are you not interested in the success of our product?", I was asked. The fact that I was programming 26-hours non-stop before this meeting to finish a feature we 'needed' to present to the customer, what my manager also knew, left me speechless (and quite angry)).
- If you agree with your co-workers on actions to be taken try to establish an environment of self-control. (We agreed e.g. on writing unit-test but one team member constantly broke existing tests without fixing them. In such a situation nothing will change if you are the only one pointing out that this needs to be fixed. But if several team members points out that the test needs to be fixed chances are much higher that this developer changes his behaviour in the long run)
- And if nothing helps / changes: quit!
PS:
I wrote several articles about my experience but they are only available in German. Just anyone is interested in it you can find it here:
http://adelio.org/softwareentwicklung-im-team-teil-1-einleitung/