Blue Ink said:
vesuvius said:
*snip*

Micromanagement is intrusive and stressful, but I came to accept it as a necessary evil. Developers (and I'm no exception) are bound to obsess on a single aspects of a product (be it an algorithm, an architecture, a framework, whatever), forgetful of when it's high time to call it good enough and start turning that shiny new toy into an actual product that customers would use and buy.

 

Our quest for high quality code is just a step from wasting time: software always rotted, but nowadays it just rots faster as platforms evolve at breakneck speed. Take any C# code that was written pre-2005. Would you reuse it? Would you ship it now? No generics, no lambdas, no LINQ, no automatic properties, shiny custom controls that just don't look right in Windows 7 (and that aren't written in WPF anyway), use of deprecated classes and methods, code that duplicates what is now in the BCL. It was perfectly fine when it was written, now it's a stinking mess.

 

Not to mention death by a thousand cuts, that is customers requiring a list of what they deem minor changes that get funded accordingly. You barely have the budget to make it work, never to make it right; that gets postponed to the next mythical big rewrite.

 

Marketing might be at fault there, but the problem is that there aren't many customers who can understand the value of good code. (Or even bad code for that matter: when they ask that their order system can optionally work in the Mayan calendar, all they perceive is the new checkbox in the options dialog... "Oh, come on, how hard can it be?").

 

This is not an apology for writing sloppy code, I still try hard to produce the best code that circumstances allow, and fight customers and marketing to get a little respect for quality. But I came to realize that I need someone, or a process, that keeps me close to reality. And, sad as it might sound, reality is that it's good enough that pays the bills.

It is always rather gratifying when one receives such a well thought out, written and thought out response.

 

I know that a lot of programmers are ill equipped to make the call as to whether a piece of code is sufficient as a solution though ineloquent. I know that there is an alarming lack of code reuse, but the proper answer I guess is that it depends. I recently worked on a project where it was all deadlines, everything had a stopwatch attached to it, and typically some of those estimations were widely wrong.

 

I typically used several design patterns, and gained time by using things like enterprise library or various SDK's, where some people were re-inventing the wheel i.e. writing their own logging system or validation system, and dealing with the web of bugs they had just created. I was more productive than others because I was more experienced, and took the time to learn how to utilise various libraries that were tested, but if you have a team with young developers, and you are pointing a gun with a stopwatch to their head, without giving them room to develop and learn higher abstractions through the numerous API's, you end up with a cowboy project and cowboy developers.

 

I appreciate and agree that micromanagement is an evil that is necessary, but you need to give younger developers the time and room to grow and learn better ways of doing things, and not always the cowboy way. In the long run it will always bite you back in the backside, as nobody seems to care about letting people develop.

 

I know that I could pass MCTS in Winforms/WPF/WCF and the .NET base test, in a month, but presently, my inbox is full, and I cannot take the time off to improve myself. I enjoy learing new technologies, but timetables now are so crammed that you have to live for your occupation. That is what I despise, because for all intents and purposes, it is a way of ensuring that people progress at the slowest possible pace.

 

A lot of the important architectural stuff I am good at I learnt when I was between jobs, I had several weeks to really drill down into SQL or WCF or whatever framework. YAGNI is a very good rule when coding, but there are technologies that are emerging now that will doubtless be beneficial. If everyone on my team had 2 weeks to learn parallel programming properly, we would produce software that will work very well, and get better as more cores become available. You try and explain the importance of parallel programming to a project manager. Thats when I think micromagement is wholly detrimental because in some ways it holds people and projects from progressing.