During my college years, I was active in student organizations. The students who were active were so well educated and brought tons of arguments for their cause. The effect was long, tedious, information packed discussions and meetings. One of the years when I attended the yearly National Student Union's meeting, I got sick about two a clock in the night. I rushed to the hospital, and after getting treatment, I could return two hours later. Since I was kind of agitated, I couldn't go to sleep so I went back to the meeting. They were not discussing the same sentence as when I had left, but had just discussed two more sentences. It was crazy.When I later became a board member for this national organization, one of the board members really stood out. She wanted to strike everything we wrote. Her standard request when we were discussing any text was to strike every sentence. Since everyone else wanted to add new sentences, I asked her about her strategy. She said that she wanted all sentences and all words to bring unique value to a text and that if you add one superfluous word, that will decrease the value of the rest of the text. I had never thought of it like that, but her words were an eye opener and I've tried practicing her ideas ever since. Do tell a story, but don't pack it with unnecessary details. Many think the more details and information, the better the decision will be. But I don't think that is true. When superfluous details are flooding us, we make bad decisions and try to put value to this information which brings no value. Our brains are hard wired to see patterns and make thing intelligible. Many times this is a blessing but in our information packed world, it can be devastating. My high school math teacher used this many times to make his assignments more challenging. By adding details which were unnecessary to solve problems, he made them harder to crack. Research also backs up that unnecessary information makes our decision making harder. In Wisdom of the Crowds, James Surowiecki points to a study performed by Jack Treynor. He asked college students to guess how many beans there were in a jar. The mean guess was 871 when there was 850 beans in the jar. A really good guess, in other words. But when Treynor added the information that the jar was of glass, the mean guess was off by 15%. The jar was of glass, so he didn't provide with any false information, but he clogged up the student's minds. We see and hear patterns. And we give meaning to things that does not have meaning. This is also illustrated in an episode on reverse speak on Skeptoid.
The journal Science published an article in 1981 by Remez, Rubin, Pisoni, and Carrell called Speech perception without traditional speech cues. By playing what they called a "three-tone sinusoidal replica", or a complicated sine wave sound, they found that people were able to perceive speech, when in fact there were no traditional speech sounds present in the signal. So rather than laughing at a reverse speech advocate, instead appreciate the fact that there is good science driving their perception of what they're hearing. They're not making anything up, they're just unaware of the natural explanation for their phenomenon.
Failing a project is never fun but in the case of my projects, they don’t result in death. Projects such as climbing Mount Everest most often result in death if they fail at the wrong moment of the project. If there is a storm and you’re near the summit, it’s a sure death. Or is it?
In this amazing film, Ken Kamler tells the amazing story of will power and how a person came back from death. But it’s also about making hard decisions and facing reality.
The power of the human mind and the human will power should never be estimated. Yes, I’m a sucker for these stories and Beck Weather’s own account for the incident is going up on my reading list.
But another reflection is that if will power can bring life and survival, bring project success; what happens in the case the will power is directed towards project failure? Do you have someone who really don’t want your project to succeed in your team? What will his will power do to your project?
I guess there are few people reading this blog who don't recognize the guy on the picture. Einstein was not only one of the brightest ever; he's a true icon. But he's also probably one of the people who has been misunderstood and mis quoted the most. When I say mis quoted I don't only mean that people falsely state that Einstein has said something. We also have the situations where his quotations are used in the wrong context and as an alternative to true arguments.I'm here especially thinking about the more vague quotations, which does not directly refer to specific numbers or research, but those nice oneliners which build up quotation databases. Direct misquotations
When it comes to the direct misquotations we for example have "No amount of experimentation can ever prove me right; a single experiment can prove me wrong". This quotation is discussed in the Swedish skeptic organization VoF latest number of Folkvett by Sven Ove Hansson. The quotation is today used by climate skeptics but when Hansson tracked the quotation, it became clear that the sources does not point to Einstein ever stating this. Well, of course he might, but there is no preserved evidence for this and the source from which the quotation derive, points to a text where Einstein says no such thing. Quotations out of context
It's all relative. If there is a statement which is pinned to Einstein this is probably it. But it's important to remember that he was talking about the laws of physics and his theories. He was not talking about health issues, history descriptions and morale. You can therefore not use his quotation as an argument for these areas.
Quotations instead of arguments
This is too often used in combination with direct misquotations and quotations out of context. In a debate, someone is pressed for arguments, validating a claim, but instead of giving this, a person present a quotation from someone else. Today, we're debating the best practices in agile software development. Scrum or Kanban? Lean software development or not? XP or RUP? These discussions too often fall back to quotations made by the big guys like Mike Cohn, Jeff Sutherland, Mary Poppendieck, Ken Schwaber. We should all be weary for falling into quotation traps out there. Also, we have another risk, which was not as evident in the times of Albert Einstein. We have the more ad hoc publications and blogs. I've been blogging for a couple of years now and much of the stuff I wrote in the beginning, I now believe to be false, simplifications or irrelevant. Perhaps I should delete those blog posts. Perhaps I should go over them, entering comments stating my current viewpoint. But I won't; for me, the blog is almost like journal, giving my current state of mind. Changing the blog posts afterwards would almost feel like changing the historic documentation. I'm very proud of that I've changed my mind over the years and I would be ashamed if I hadn't. But this does not mean that I would want anyone to use those old texts as the sole arguments in a discussion. As a complement to your own arguments, a quotation from someone else can help building your case, but a generic quotation is not an argument in itself.
Sometimes software development feels like when I doing gymnastics in my youth. Just like the boy on the picture, you start your pace slowly, carefully. You know where the finish line is. Then you start to wobble. Trying to keep yourself up, you increase the speed, hoping that you will make it to the other side. Often you didn't and fell down. Other times you barely made it, just to crash on the other side.To some, this happened sometimes, to others it happened over and over again. Somehow, the repetition did not help in the learning process. Another example is from when I was taking my driver's license. Here in Sweden you must complete training on icy roads. The teacher used a very clear method. We were instructed to go around the course a number of times. The first time we were told to keep a specific speed, 30 km/hours. Everyone made it. Then he told us to go 50 km/h. No one made it. And then he told us to change whatever we thought suitable to ensure that we would complete the course. 20 out of 21 students decreased the speed and made it. One kept up the speed and of course he didn't make it. As he could see the speed of all the other drivers, one would guess that he would understand but when he was given the chance to again change anything to complete the course, he didn't change the speed and was again the only one not to complete the course. I really hope that guy never got his license but we all know those guys are out there, those who just speed up, crashes and never learn. And when those guys are into software development, there are failed releases. Change This is a wonderful little site, dedicated to change and one of the manifests discusses product launches but it can as easily be applied to any software development delivery. There are some handy rules out there and what I like most is the integration of outside stakeholders. In the manifesto, salespeople are mentioned but they can as easily be anyone caring for the software on which they depend. Happy reading. http://changethis.com/manifesto/issue/68.05.ProductLaunch#view
To change your Internet password manually, enter the URL for a Web application and add “?changepassword” after the database name at the end of the URL. For example, http://serverName.acme.com/databasename.nsf?changepassword.
In the Change Password screen, enter your old Internet password, enter a new Internet password, and then confirm your new Internet password by entering it again in the corresponding fields. The password quality guidelines are the same as the Lotus Notes password guidelines.
My blog post about my friend with the failing supplier resulted in one of my developer friends thinking that I was developer bashing. Not all customers want to pay for bug free software. And I agree. Most seasoned software users knows that there are always bugs in systems. The costs for those last 10% is higher than most of us are willing to pay so we find them in most software. Of course there is software where there's a 0 bug tolerance within for example aviation and medicine, but if we look aside from that my friend is correct.But there is a big difference between small annoying bugs which is not spotted until you do something that is not easily expected and bugs which becomes apparent after just a few minutes of testing. It's a big difference between bugs which are annoying and bugs which makes the system not usable. In the matrix we find these bug definitions. Most bugs are annoying and can be spotted using standard scenarios. That they are there is often no surprise to the team but priorities have resulted in them not being done. When I say annoying it could be that the bugs makes the system useless to one or a few users but it works for most users and that the main purpose in reached in spite of the bug. I would say that the annoying bugs which are only spotted using special scenarios are inevitable and also acceptable to most users. When it comes to the bugs which makes the purpose of the system not being forfilled we have the bugs which are not easily spotted but anyway makes the system useless. These are the oops of the system. The things we hadn't thought of. These are costly to find and I think that in most cases customers can accept that this happens. But what about the bugs which makes the system useless and can be spotted using standard scenarios? Many years ago Microsoft released a version of Microsoft Excel where the print functionality didn't work. Here we find the bugs which me and my friend where discussing. In his case, ll deliveries have bugs of this category. So, who is responsible? I would say in principle the manager is responsible for the problem and if there was any bashing in my previous post it was management bashing. BUT the developers of the team should, if they had any pride in their work, should also feel a responsibility. I don't think it's about laziness, my experience is that these bugs are often a result of taking on too much and not making sure that no bugs in this quarters leaves one's desk because you're eager to start with the next task. Of course it happens to every developer that such bugs sneaks through the cracks and that's why we have testers. But if every delivery is infested by these bugs, this is more than just mistakes.