I had the same reaction when I was a kid and saw The Black Hole. I own it today, and I fully agree it really is a dark sci-fi movie; it's one of my favorites.

Honestly, I prefer it over Star Wars.

As an aside, did anyone else notice that in Tron 2, when Flynn's son first enters the virtual world, makes his way onto the 'command ship' and meets (I think) CLU for the first time that the command room looks exactly like the command room on the Cygnus from the Black Hole? The little pods sunken into the floor and the ledge going around the edge? Is it the same set? I always sort of wondered if that was a nod to the other movie.

I used to think this way, then grew up and realized that tools like IntelliJ and Eclipse are useful and have features that give me more insight into the code I'm working with and help me do my job more effectively. The tool is just a tool, and any tool will let you do things you're not supposed to do if there are not processes in place to prevent it. This is where the attitude of the business, coding conventions, code reviews, unit tests and other processes come into play.

Put more simply- if this were construction, I'd say it's not the hammer's fault the house was poorly built.

I know. I was actually just trying to put into words the ridiculous cartoon that was in my head.

You raise an interesting point. I think the scenario you describe is an ideal situation for something like that, and there's value in it because you're communicating information to another group. I agree that ritual for the sake of ritual is meaningless.

Maybe the difference is that, with a morning standup, you are essentially giving yourself a shift briefing on the work you just did the day before. That alone could make it meaningless. Maybe the value of the morning meeting is proportional to the communication dysfunction within your company?

Not even close to the same thing.

Well, not unless every person in your morning company formation sequentially breaks ranks, runs to the front, does an about face and gives a personal status:

"Company! Yesterday, I did a lot of pushups! Then I low-crawled! Then I cleaned my weapon and did some more pushups! Today, I'm going to walk a lot! My impediments are the group of people across the wire trying to kill me! Hoooahh!!"

I agree with your sentiment.

I'll veer off into the woods a bit. At my company, we recently switched to scrum and it gives clear visibility into who is adding all the extra, unnecessary work and scope creep that comes with people not quite doing what they are supposed to be doing. What I really like is that it also gives developers a tool to push back with when they are asked to switch contexts, re-prioritize what they are doing or take on new work via scope creep.

Team structure seems to play a larger part in things than I hear people talk about. Trying to find a balance between inexperienced and experienced developers is difficult, and we've pretty much always come up on the wrong side of it. One of the other fundamental imbalances I've seen (at least in our organisation) is that, within the context of a sprint, the developers are usually capable of doing everyone else's job- but the reverse is not true. I've seen this turn into situations where developers end up doing BA work, QA work and supporting production issues while trying to keep up with the development tasks that are on the board. Meanwhile, everyone else is just sort of sitting around, trying to look busy. In my opinion. this is a management failing more than anything, but it is still an imbalance.

This could just be how we apply (or misapply) things, but what I really wrestle with is the idea that ultimate accountability seems to rest with the developers, but others don't seem to be held to the same standard. Agile (I can only speak to scrum) seems to provide a framework that offers to give developers more power in exchange for more accountability- but none of the processes that give the developers what they really need to deliver on what is required seem to fall under that same framework. Scrum seems to declare things like figuring out specific requirements for what you're trying to develop outside it's scope. This means that when other areas of the business don't do what they are supposed to, the developers end up having to deal with it in some capacity. Since they are the ones on the hook, that usually means doing someone else's job. Developers are motivated by the sheer number of eyes focused on them, but where is the motivation for everyone else involved in the process? Even this book review seems to only talk about rewarding (or not) developers. There isn't mention of the other groups that feed the process.

I'd also go waaaay out on a limb and argue that misapplied agile seems to have the potential to kill vision within a company. By forcing people to spend the majority of their time thinking only about what they can deal with in terms of this (or the next) sprint, it seems long-term vision with respect to a product has the potential to get lost. In other words, if there isn't a cohesive vision of what you're trying to produce, you could be reduced to a team of developers who only have the ability to react to situations and stare at the technical debt you've accumulated by switching directions so many times. That's probably a bit melodramatic- maybe that potential exists regardless, but scrum makes it easy to see how that could happen.

Ok, enough ranting.

Part of the reason may be that the back-end storage for that particular site is a legacy system and limiting users to ASCII characters ensures that the byte length of all entered characters is exactly the same. Otherwise, a user might be using a charset that provides for umlauts or something. In UTF-8, for example, the higher order characters could use 2, 3 or 4 bytes of storage.

Assuming you are on a website, your password could still pass form validation because the character length passes muster, but behind the scenes you are using more bytes than anticipated. This could cause the stored data to extend beyond the length of the column, causing the DB to truncate the stored password and therefore corrupt it.