""Not Invented Here" syndrome: Expressed most commonly in a desire for everything needed to be developed in house. E.g.: “Need a CMS? Let’s make our own from scratch!” Perhaps, you work at a place where all your teammates do is constantly bring you bad ideas. Are they really all terrible? Or are only your ideas good enough for the organization? Not Invented Here can also apply to your own head, not just the organization."
The answer is yes, they (CMSes) are all terrible. :)
"No dedicated QA for externally-facing software: Someone who is experienced at breaking software should have a crack at it before it goes to users. Developers (including me) are too enamored with their own work to really take the time to break it, so someone with a sense of pride in finding problems needs to be given the task."
Having dedicated QA is not always good. In fact it is often counter-productive.
"Low Joel Test score: The Joel Test remains a great indicator of institutional ego. A team that scores low on the Joel Test does so because someone along the way decided that, "nah, we don't need that here, we are special", and almost certainly they are not. I have yet to hear of a team with a legitimate reason for a low Joel Test score."
The joel test is actually quite out of date. Specifically the stuff about fixing bugs before writing features, hallway usability testing, testers, having a 'spec', and having a bug database are all not necessary or good to have in all cases.
> Having dedicated QA is not always good. In fact it is often counter-productive.
Maybe 'dedicated QA' is a bad but a developer must at least be point man for test, even if the responsibilities aren't 100% of their workload. One could argue that having a horde of peons to click randomly is counter-productive, but teams >6 or so need a specific dev responsible for automating test. Its too specific a domain, and intermittently demanding, and to force all devs to split the duties.
I wouldn't say that a perfect score means you are good to go, but just that it is a list of things that either should be addressed or deliberately discussed and weighed. You want to make sure that you are leaving in known bugs, not using a bug tracker, or not having requirements for a a very good reason. If the reason is "we are a one man shop, and I am fine without it", OK, just realize that will not scale very efficiently.
I'm curious about this. What do you do when you encounter bugs that have a longer fix period, say several days to a couple of weeks? Do you stop new development or are you dedicating part of your team or team's time to only working on bugs?
Often I don't need a "Content Management System", but I need a way to "Manage Content". The 'system' part is... pretty much in every situation I've seen, a straightjacket with little room to be extended, or something which requires a lot of time/effort to be proficient with. I've still not yet found a good middle ground.
Anything not at either end of that spectrum (I'd argue Wordpress, for instance is dangerously close to being an example) is a compromise which shouldn't exist because it will incur a heavy maintenance burden (greater than the limited but simple solution) in exchange for it's flexibility which it might not be able to pay back as well as the fully flexible solution.
Assuming content management is the key goal; I tend to use either a static generator (limited, purpose-built, ultimately simple) or Drupal (approaching becoming a framework that happens to ship with a CMS, has a learning curve from hell).
For someone that needs more than the simple use case, my suggestion is to delegate to a guy who has spent a long time and cleared the hurdles to proficiency with one of the flexible-at-expense-of-complication CMSes. Though, I'm one of said guys, so I'm biased.
Obviously, Drupal's not exactly pretty (and PHP is a lot of fun to hate) but I find that it comes with code I don't have to write to scratch enough of my customers' itches for me that it's hard not to love it anyway.
The answer is yes, they (CMSes) are all terrible. :)
"No dedicated QA for externally-facing software: Someone who is experienced at breaking software should have a crack at it before it goes to users. Developers (including me) are too enamored with their own work to really take the time to break it, so someone with a sense of pride in finding problems needs to be given the task."
Having dedicated QA is not always good. In fact it is often counter-productive.
"Low Joel Test score: The Joel Test remains a great indicator of institutional ego. A team that scores low on the Joel Test does so because someone along the way decided that, "nah, we don't need that here, we are special", and almost certainly they are not. I have yet to hear of a team with a legitimate reason for a low Joel Test score."
The joel test is actually quite out of date. Specifically the stuff about fixing bugs before writing features, hallway usability testing, testers, having a 'spec', and having a bug database are all not necessary or good to have in all cases.