I would say your right on point about everything except high performers.
- I think things can get over-architected which is just as bad as spaghetti code.
- Made sure design and code is reviewed early in the process nothing like getting code done and unit tested then finding out the day before codes is supposed to move you need to redo everything(even if it works.) And treated like you screwed up. People don't know what they don't know.
- I'm a "quick developer" here are good short cuts in my opinion.
1. I worked on lots of easy stuff because most developers like to work on the challenging stuff. But it still needs done. Although, I do my share of hard stuff too.
2. I test as I go. I don't trust my own code. Test every 5-10 lines of code. the better the developer the more they think that one line of logging code doesn't need unit tested.
3. It's easy to change a doc than code. A lot of times there is ambiguity in a spec. Analyst and QA don't want to change stuff just as much as developers. If the business is ok with the code then change the doc.
4. I try to follow convention and talk users out of stuff that will take a long time to develop but add little value.
- watch TDD. A big part of QA is 2 eyes are better than 1. You lose a lot from having the same person code and code tests.
Yes. Unfortunately, the cure can be worse than the disease. At least spaghetti code _does_ something, even if it does it more slowly and more resistant to change than something theoretically might. I'd estimate that half of my career has been spent fighting with "enterprise architects" who want to roll out "enterprise solutions" (i.e. third-party software products with questionable support and nightmare licensing conditions) in a misguided attempt to avoid writing even one line of code.
Thank you for writing this essay, Bill. I've been wanting to write a post like this for a long time, but you've stated my thoughts so clearly, I will just send this link.
[+] [-] sharemywin|9 years ago|reply
- I think things can get over-architected which is just as bad as spaghetti code.
- Made sure design and code is reviewed early in the process nothing like getting code done and unit tested then finding out the day before codes is supposed to move you need to redo everything(even if it works.) And treated like you screwed up. People don't know what they don't know.
- I'm a "quick developer" here are good short cuts in my opinion.
1. I worked on lots of easy stuff because most developers like to work on the challenging stuff. But it still needs done. Although, I do my share of hard stuff too.
2. I test as I go. I don't trust my own code. Test every 5-10 lines of code. the better the developer the more they think that one line of logging code doesn't need unit tested.
3. It's easy to change a doc than code. A lot of times there is ambiguity in a spec. Analyst and QA don't want to change stuff just as much as developers. If the business is ok with the code then change the doc.
4. I try to follow convention and talk users out of stuff that will take a long time to develop but add little value.
- watch TDD. A big part of QA is 2 eyes are better than 1. You lose a lot from having the same person code and code tests.
[+] [-] clifanatic|9 years ago|reply
Yes. Unfortunately, the cure can be worse than the disease. At least spaghetti code _does_ something, even if it does it more slowly and more resistant to change than something theoretically might. I'd estimate that half of my career has been spent fighting with "enterprise architects" who want to roll out "enterprise solutions" (i.e. third-party software products with questionable support and nightmare licensing conditions) in a misguided attempt to avoid writing even one line of code.
[+] [-] akeck|9 years ago|reply
[+] [-] greenyoda|9 years ago|reply
[+] [-] cema|9 years ago|reply