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.
Well said. I spent hours yesterday setting up a bunch of ORM make-work, rather than getting a connection to the DB and just doing a bloody query, for a "spell check" function.
All I needed to do was get the intersection of the set of user provided words (candidates) and the set of approved words (a text column in a dictionary table). Conceptually, I needed a prepared statement or query build to do something like:
select dict.word
from dict
where dict.word in ( ... candidates ... )
(the difference of the candidate set minus the result set being the unrecognized words)
But I had to drag in entity models with magic incantations, er, annotations, and repositories and a predicate factory class and multiple config files -- for a dictionary table that is rarely if ever updated, manually; it exists for this query. Sadness.
If I knew the Spring/Hibernate/JPA stuff better, it of course would have been easier, but what a pile of tripe to have to read through for the life of the project.
Also, good point about the seeming terror at the prospect of EVER deviating from the proscribed Enterprise Design Patterns (embodied in crappy trendy library of the day) to do such "crazy" things as perhaps write your own abstraction / wrapper (line of code) that better fits what the given app actually needs to do.
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.
- 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.