A completely lack of documentation and tests
Wow! What can I say? I have created 2 great web-application at work (and they sell good!), and none of them has one single line of documentation or test classes. I would probably get arrested by the coding police, but to my defence I can say that I haven't got the time. Short deadlines, and other things to do right after. I know this is the situation for many developers, but the first thing you cut out for saving time and money is - exactly - documentation and testing. In addition, I have worked alone on these web-applications so there has been no need for others to dwelve into my codebase. Good names on methods and classes have been enough documentation for me.
Workarounds
Instead of doing it the right way, I also have been tempted to write a little workaround here and there, which saves me some time. I know that I may regret this later on, but chances are good that the code works for a long time. (Maybe you refactor the whole codebase long before you have trouble with the workaround)
GUI
Since our company doesn't have its own dedicated designer we programmers often do the GUI work ourselves. I don't like GUI work. So my html and (non-)css habits may cause shock for a real designer, with his floating div's and liquid css layouts. What's wrong with a couple of tables?
"Hands against the wall! My friend, you are under arrest!"
With that being said, I can now move on to something more important. Our company makes money. A LOT of money. I have now listed many of my bad coding habits, but one of my best qualities is the fact that I work fast. I am good at estimating, and usually finish projects within deadline. My product managers are satisfied with my work and they do certainly not care how my codebase looks like as long as I finish as soon as possible.
So what answer do you think I get if I ask them for a little more time to document my work? Or introduce a testing framework?
"'Why? Is it necessary? Can it wait? It's this other project that's really critical."
Time is money. It's not that I make ultra-fast crappy code that works for a week. My applications work fine. It's just that I may take a shortcut when offered, and I haven't had any needs for taking the time to documenting my work or writing tests. Until now....
Next time, I will be writing about big changes in our small development environment that surely will change the way I code. I do not work alone on my products anymore. I am now a part of a team. We must work together. And our team must collaborate with other teams. Routines, separation of concerns, bus-factor, ownership and readability are some of the keywords
Innlegg
2 kommentarer:
It's the same in big company's as well. What do you do when your superior only sees the number of used hours, and you know that you could perform this task in that amount of hours but it will come at a cost: You spend x times the hours in upcoming error corrections and hotfixing! So it's not easy to make a wise decision, but i always have enough to do, so i shouldn't complain;)
Looking forward to the next post Martin! Keep up the good work!
Nice article, Martin.
I think your statements shows that you are used to work alone. And in this scenario your article makes much sense. In a team effort, I think you will have a lot of challenges, as I suspect your next article will address?
Of course your product managers will say: "Why? Is it necessary? Can it wait? It's this other project that's really critical." What did you expect? Code documentation or test frameworks (or any other framework for that sake) has never made them any money. Documentation, refactoring, continuos integration and automated testing should be a way of working, not something you should ask for extra time to do after you have made your delivery.
Speed is essential, but speeding can be dangerous. If speeding causes you to spend x% of your day doing bugtracking, hotfixes and unnecesary support, then perhaps your product managers are better off with you keeping the speed limit? Perhaps they would get even better mileage out of you:)
I think it should be allowed to take shortcuts and do workarounds as long as it doesn't adversely affect the quality of your application, your future speed or the work of your colleagus. In this case, it's not a workaround, it's doing it right!
I claim that your best timesaver is: Do it right from the start!
Legg inn en kommentar