Why So Long To Release the Apple Watch?

Developers need watches. Developers are the ones that can't keep secrets :o) It is also pretty hard to beta test a watch in the real world world without going into the real world. At some point you have to go public. Of course there are other reasons, like some issue with production (odd the demo units at event were true demo units), but these other issues are just as likely. Even with build issues, you still need to get the watches that do work out into the world to see what else breaks.

Musings of the Sorry State of Developer Accountability

Things I see...

5 minute change takes three days.
Screens developed don't look like screens delivered.
Data developed is only marginally like data specified.
Developers concentrate on code, not understand what they are coding and why.

It all falls down to this: Developers don't take the time to plan, they just code and make things up rather than understand why, create a plan, execute and validate.

Why is this happening? Management... But that's just pointing fingers. Management has not really caused a problem. Yes management wants it right now. The problem is that programmers are fighting for their jobs and feel like they must do everything that management says. There is no give and take. There is no negotiation. Programmers don't think and push or pull to get it right, they just do what management says and the blame customers/mangers for being unreasonable and causing the errors.

This is akin to war crimes. Really. Sorry. I just did what my superior said. I am but a soldier and not responsible for the crimes of my superiors.

Projects fail, applications crash, customers complain, data is corrupted, core capabilities don't exist or are so wrong that they are so poorly executed that they can't even be compared to wrong, let alone close to right.

Nothing can fix this but personal responsibility and pride in your work. Agile, Scrum or any other process is useless. If you can't fight for doing it right, please go home.

Associative Reality

Aggregation (white diamonds), composition (black diamonds), simple associations, directed associations, and ownership(containers) are steak and potatoes of object oriented structures and our favorite modeling language, UML. I recently worked with a client that used composition for parts of a configuration rather than aggregation which seems logical given the reuse of parts between configurations. This was SysML, but the standard used the common UML concepts and meaning. The customer used composition for configuration relationships because the concept itself was light weight, i.e. the car configuration was a configuration of car, not a true car.

You might say an illusion owns elephant, thus when the illusion dissipates, so does the elephant.  Or for you dessert rats, the water in the mirage is gone when the mirage is gone. In a car, the parts are created and destroyed like arms and legs, but when we stop creating a model of car, it ceases to own the responsibility for those parts. Another model of car may be composed of the same radio, but they are not shared nor does deleting one car model destroy the other's parts.

It may be that we are always struggling to pin our hopes and dreams on our ability to control our destiny through these concepts when they are the wrong hopes. Take for instance, directionality of relationship. This is pure software isolation, not system engineering. What if I know your name, but you do not know mine... yet? Is that bidirectional? Does an engine know the transmission it is connected to and vis versa? Yet both have effects on each other via linkage.

Aggregate/composite/owns are software terms and perhaps not as applicable to the real world. It would be interesting if we dug into the haggis of software concepts to find why and where these terms originated. They certainly loose their shine when applied to systems engineering.

Moon Buggy

Was watching Moon Machines on the Science Channel today. Here is a great quote from Alex Kosmala, Flight Software Developer, MIT Instrumentation Laboratory:

There were no specs. We made it up. And its always amazing to me, why was I allowed to program something that hadn't even been specified, that would be critical in assuring the success of the whole Apollo space program. I couldn't believe it. But, that's the way it was. We made it up as we went along.

UML helps you prevent your brain from exploding

Yep, UML helps you keep your head. Just take an actor in a use case diagram. Why is it a stick figure? Perhaps because we are not artists. Imagine having to draw whistler's mother everry time we're representing a user. Go ahead, we'll wait for you to imagine how hard this would be.

What about class diagrams? Think about it for a second, based on how hard it is to imagine a couple thousand lines per class of spaghetti (just  100 lines lasagna if you are good programmer). A class diagram symbol is just a symbol. At most we define name, attribute and method signatures. We do this for good reason. To add more detail implies we actually can absorb, understand, and remember the complete program.

The facts are, we are sloppy and lazy. We can't keep  more than a few things in our heads at one time. Sure we match patterns, but not thousands of lines of Java at the same time. We think linearly. We also are not savants with photographic memories.

Sorry, no idiot savant here. We need a crutch. That's UML.

Developed by nerds, not artists, UML is a cartoon of symbols, not a detaied 3d representation. UML is ugly and unimaginative. Ugly is good. You don't buy ugly a new car from irrational imaginings of a good time.  Ugly is functional.

People complain that UML is confusing. Sure, that's true, but only if you don't understand UML, or objects, or in fact have the ability to abstract life and the world. UML is just a language of symbols. You need to learn to read and write before the alphabet is really useful.

Ok, enough. Go learn. We'll be waiting.

Proof of Life

Avoid addressing problems, issues, events, or constructs that are not proven to exist in the real world. This is like "proof of life" used in hostage negotiation. Here you should not proceed until there is proof that the need either exists or there is a commitment to existence.

Proof of life or existence of a concept in the real world should be confirmed before allowing a concept to be added to the process or metadata. Simply, there are things we imagine that might exist that do not exist in reality. Imagination and antidotal-based evidence lead us to create scenarios that are not realistic. We need to limit effort based on impossible or rare edge cases.

Dealing with edge cases and error conditions is important. How exceptions are dealt with can be designed so that the effort is applied at the exception, rather than designing expensive infrastructure to solve a problem that may never occur.

We hate failure and that is why we come up with many scenarios that may only be imagined. If something might happen, we believe it actually does happen. The difficulty is proof that will satisfy a critic. The best case is that without proof, we cannot assume it is necessary to address or that we address with a lower level of effort. Those things that have definitive proof have priority.

It is important that our primary modeling tool is UML-based with UPDM, SysML and other standards. These give us all the building blocks and levels of abstraction so that we avoid reinventing the wheel. We also have one place to look for what we have proved to exist and even what does not. Unlike cowboy-agility where we erase the whiteboard on every iteration, we have a history that gets smarter after each iteration. Don't be afraid to document an activity and add metadata to classify it as 'do not implement.'

Address primary use cases and important edge cases, but should not attempt to address those that cannot be proved. There may be guidance for addressing such unknowns and ensure that efforts are reviewed to ensure success.

A good test of "Proof of Life" is a repeatable and complete test. If you can create a test, then it is at least possible to show the exception in practice. This works well for software, but also applies to your development process and any automation and metadata of the process.

Why Software Sucks (more than it should)

Here at Boys Books we were breaking in another software slave (intern). As usual we waxed poetically (actually dirty limericks). We grumbled about the olden days when software did interesting things and worked in expected ways. This is of course a lie. Things are vastly better now, they just suck more.

If we can create a vacuum that never loses suction, why can't we write software that doesn't suck?

We think the real reason is the invention of railroads. One track minds have plagued us as a metaphor ever since the iron giants rolled across the American plains scarring prairie dogs. The common programmer seems to be trapped on the tracks with just one goal at a time in their heads.

Ask a programmer to create an game. They will create a great game, but that's all. What they won't do is make it easy to learn, simple to install, and other useful things like integrate with facebook and worse, won't show up on google. The game will be one dimensional suckyness.

You might say, "My iPad games were easy to install." Well, that's one. But why was the game easy to install? Because Apple installed it, not the programmer. The game might (and few are) be easy to use. Again, the only reason is iPad's touch interface and accelerometers. The same game would require the user to memorize fifty keyboard commands. The programmer is still on one track, but the track is happily going through some scenic parks rather than a toxic waste dump. The same programmer in front of a PC is still writing the same garbage.

What is the solution? Jump the tracks! Toss a few pennies in front of that train and derail it! The pennies are the imperatives that we know as who, what, why, when, and how. Programmers just have the rails of what and how. They need the rest to really get things moving.

But don't stop with the imperatives. We need to also have time, location, emotion, motivation, least surprise, novelty, and a web of connections to all of these concepts and the imperatives.

Why shouldn't the game play differently based on your location? If you play a driving game in Dallas, half the drivers have guns (and use them), and the other half of drivers are moving at ten miles under the speed limit and have Oklahoma license plates. See what just location adds? What about 'when'? Imagine racing at rush hour or through cop infested school zones in the early morning?

NOTE: These ideas and concepts copy write by Daniel Brookshier. All ideas are for sale at a reasonable price.

The Zombie Plain

I have just come back from the programming zombie plain. In this case, the Android operating system.

If you are a 'real' programmer, you have been to a zombie plain. To others, you seem as shuffling oblivious to the rest of the world, except for one goal that common humans cannot fathom. Like a regular zombie, you are preoccupied with the ultimate goal similar to a succulent brain.

My adventure was a little disorganized. I had never programmed on Android. I had a few books, but to put it simply, these books were written by other zombies, perhaps possessed as well by a publisher with a deadline, not humans. I am a great Java programmer, but Java is only as good as your tools libraries, and documentation. Sadly I was missing all of these and was stuck shuffling in search of a design that works.

The menu items of zombie programmer are the little pieces of software you need to get working. With standard programming, these are hard enough to all make work at once, add a phone OS and we have a whole new level of desire for our gray matter. Phones now have their own user interface libraries, special ways to configure, wacky features like a screen that rights itself to the correct orientation (maybe), and worst of all an application lifecycle that starts and stops the application because of slightly more important tasks like phone calls or an important email. Mobile phone programming is like taking the simplicity of zombie brain chomping and moving upscale to cook your brains in the style of French cuisine without a saute pan or a whisk (a good merlot brings out the overtones of neurotransmitters).

Back to the shuffling of the zombie programmer. As a zombie you go from one scent of brains to the next. Zombie victims of course do not just sit there and wait for you to finnish spooning their cranium, they keep screaming and running away. Same is true with programming and worse on Android. Fix the screen to work great in portrait mode, then it stops working in landscape. Get landscape and portrait to work and suddenly the app won't talk with the camera.

The tools you use are another matter. They are akin to the shuffling. Zombies are not coordinated and neither are most development tools. Just when you think you have solved your problem, nothing seems to change and the application too is undead. This is of course a ruse. The tool is simply playing undead to fool you. Really your fix worked, but you keep shuffling on to other solutions that all fail to work and you probably forget the best fix that would have worked if the tool was listening to you.

The tools for Android are quite tricky. Once they figure out how to fool you, the only choice is to shut it all down and start again. Luckily most of the evil goes away when you hit reset. Sadly there are still things the tool remembers. The debugger might work again, but you can't compile because some setting was permanently munged. Between resets, you are blowing things away and starting over. A fine example of this evil was adding a sound file. Add a folder and the file, it stops seeing this R.java file. If you add the folder, delete the generated R.java, then add the sound file, it all works. Sadly though the sound file won't load...

DISCLAIMER: We here at Boys Books don't want to mislead you. Everything here is true. However, it is our own alternative universe of truth. Try this on another computer or someone other than your identical twin, or evil twin, it really does not matter, all the problems are all different with solutions to our issues are unrelated to yours. The only truth here is that Android programming is like a vacation at a high-priced beach resort, in Hell. This is why programmers are generally highly compensated, it's hazard pay and helps pay for PTSD therapy.

Zombies are never satisfied. Same goes for software developers. Here is the problem. Applications should have lots of features and of course be perfect. What the brain can imagine, the programmer must develop. Imagine writing science fiction. You imagine a big spaceship that travels faster than light. Now imagine building that spaceship... That's the joy and frustration of programming. Cool to imagine, satisfying to know you are creating something cool, but frustrating because of the impossibility of the dream. Oh, then add wacky tools, sad libraries, and programming languages that are not very good at mind reading.

Welcome to the zombie plain!

Business Analyst Wanted

A break from the ordinary. I am looking for a Business Analyst with BPMN.

The jobs are in London and up state New York. This is in Banking and concentrates on Risk Management, Disaster Recovery and other aspects related to financial and operational risks.

Need three people in each location. This is for Business Analysts skills and specifically the ability to create models with the BPMN standard (Version 1 and especially version 2). Not too picky about being in banking, but it helps. Mainly looking for the ability to do a mind meld of a business and document in BPMN.

At this time I am unaware of rates or duration, etc. Given that it is for six people, it smells quite big. This will be with No Magic.

So, if you feel this is your cup of tea, call 214-291-9100 and ask for Jim Rice our head of services. If this is not in a comfort zone and you have some friends that can play in this area, please forward the email.

Why does UML seem so hard?

I wrote up the following in response to Why is UML So Hard? I have edited a few things, but the message is fairly timeless. The blog, called CRAIC PROPAGATION, that I am responding to was not just that UML seemed hard, that it also produced poor results. With that context, lets get into why UML 'seems' so hard.

I have been doing UML now for approximately forever... at least in software years.

I am also the chief architect at NoMagic, producers of MagicDraw UML. So I am a little biased, but only in this job for a few years, so not born into the religion of UML because of the signature on the paycheck.

Here's the problem: UML is a language. Just like you might experience with Java, if you don't get it, you don't have it.

Just because you know English does not mean you can write the great American Novel. You need to know how to model to create a great design. UML is just syntax for the model.

When you come to my class, I teach modeling. The syntax of the larger pieces of UML sort of disappear because of the approach which is to only model certain things at one time.

The biggest problem people have is levels of abstraction. Most people have verbal diarrhea when they model. This causes most of the problems.

Another issue is people seem to forget about requirements. Requirements have a bad name, so let me say that these are just simply statements about what the design 'must' do. The more you constrain your design to fulfilling the requirements, the fewer issues you will have with pointless models.

There are two new OMG standards that have been added. UPDM does enterprise architecture. I love it because it forces you to think about software in the context of its use.

The second is SysML. It was created for engineering. However its most useful and strangely simplistic feature is the ability to model requirements and relate them to your design and tests.

But why is UML so hard? Most people are allowed to simply do, not learn and perfect their modeling skills. There is not a silver bullet unless you have the skills to shoot the gun and hit the target.

I am working on changing this in our tool. We are adding wizards, helpers, and even a little artificial intelligence. It won't make you a world class modeler, but it will keep you from shooting yourself in the foot.

Two ways to program

Below are two flowcharts that describe the thinking process of two types of programmers. On the left is what I would call 'good' and on the right is 'bad'.

Programming is not just coding. There are a lot of things to do. But what you normally see is what is on the right. The programmer is given a problem and they try to throw a technology at it.

On the left, there are a lot of things to do before you ever get to programming. Not saying that there isn't a little experimentation. This diagram is a summary, so there is some wiggle room, but the good developer does something related to each subject we have outlined.

You might ask why these two are so different? The first reason is time. Often a developer is assumed to be programming, not researching and designing. The second reason is that the first diagram does not have a lot of feedback to the customer and people in general are results oriented.

You might also say that the diagram on the right is Agile. Yes it is Agile, but it does not create any real design data other than the program and the testing is only done by the user.

You might also say that the second diagram is wrong because it is missing much of what defines Agile. This is a fair criticism, but again, this is just what most programmers do, not what they should do.

The first diagram could be expanded to be iterative, but I left that out for a reason. The fact is that these are tasks that should be required or verified if you are forced to do waterfall or you are ding XP or Agile. Each point should at least be considered or you rely on recorded information gathered on prior iterations.

What is the message? There are no shortcuts!

Programmer Thinking

Software development is problem solving. Simple enough, so why is it so hard?

The reason that software development is so hard is that we are solving many problems at once:

1. Solve the problem conceptually.
2. Design the user and data interfaces to allow the problem to be solved.
3. Use the API and language to implement the solution.
4. Create this in a context that executes the language and the APIs you have used so that it scales to the size of your user base.

There are a lot of assumptions too:

1. You understand how to solve complex problems.
2. You understand the problem domain which may be many domains.
3. You understand your programming language.
4. You understand many different libraries and standards to use as part of the solution.
5. You understand principals of good user interface design.
6. You understand basic principals of data design and perhaps database design.
7. You can think through your basic knowledge of the items above in a way that can create a viable solution

The productive programmer has all these skills covered or has learned how to quickly learn any one of these quickly to fill a gap. Can you begin to see why programmers are a specialty?

Shibboleth Software Developer Interviews

A Shibboleth is a type of test and was invented to look for impostors. Essentially you have a word that a foreigner can't say properly because their native language. This test goes all the way back to the Old Testament:

Gilead then cut Ephraim off from the fords of the Jordan, and whenever Ephraimite fugitives said, 'Let me cross,' the men of Gilead would ask, 'Are you an Ephraimite?' If he said, 'No,' they then said, 'Very well, say Shibboleth.' If anyone said, 'Sibboleth', because he could not pronounce it, then they would seize him and kill him by the fords of the Jordan. Forty-two thousand Ephraimites fell on this occasion.

So, first thing to notice is that this particular test resulted in a heavy penalty. The second is that if you have a speech issue, you are probably out of luck.

In WWII soldiers used a knowledge of baseball to detect friend or foe. Imagine if you were a football fan back then...

What I do like is that this a reasonably good test for interviewing software developers. I wouldn't worry about exact pronunciations, but phrases. Phrases are much more powerful indicators of impostors.

The one tool that I usually test a developer with is love and anger. Ask what the developer loves about the language or the API you need to have experience in. Then ask about what they hate. Unless you have great actors, they will fail these tests if they are not real experts or experience.

Don't just test your code, test your developers!

Artificial Stupidity

Artificial Stupidity (AS - pronounced rudely as you would expect) is an important discipline and I believe a growth area in computer science.

Look at the things we can do with AS:

• Dumb monsters in games
• Automating the news reporting at Fox News
• Anticipating typos or mistakes
• Turning off computers in the cockpits of airplanes that are overshooting airports
• Politicians
• Testing of artificial intelligence
• Thesis committees for AI doctoral candidates
• Better ways to annoy MS Word users with silly assumptions about spelling or formatting automation

Actually there are endless applications for AS. You could do a Turing Test that if the human agreed with the AS, we could confirm the human is a politician, mid level manager, or works for Fox News.

There are many places to learn about AS. For example, NASA. Not the space flight NASA, but the National Artificial Stupidity Association at the University of New Mexico.

Unfortunately this is sot something you can get a degree in. You have to specialize, maybe write a book or make it part of your doctoral thesis (writing one book is the equivalent of 300 blogs or a doctoral degree).

The funny thing is that there are already a lot of AS professionals (or is that AS pirates?). There are a lot of smart folks out there, but some are just plain bad. So, write bas AI, you automatically become an expert in AS.

AS's are everywhere! We have been awaiting self aware machine intelligence, but I think we see AS emerging right now all around us. Look at MS Word and its auto-formatting for wonderful example. Even though a lot of software was designed with traditional techniques and no AI or expert system code. Airline sites that pick only pricey tickets, shopping carts that forget what you bought, most applications have become 'self stupid'.

JRuby Trick: Saving time instrumenting Java classes

Ever with you could teach a class a new trick without wrapping or extending capabikities in a new class?

One of the issues I initially had issues with was extending Java to do cool things with Ruby.

First the Java class:

public BoringPig{

public String getName(){

return "name"

}

}

Being a Java guy, my first attempt at adding Ruby to Java looked like this:

class FlyingPig

def initialize(boringJavaObject)

@boringJavaObject = boringJavaObject

end

def flyPiggyFly

# ..... exciting stuff,

puts @boringJavaObject.getName+ " is flying!!!!"

end

end

But this meant I had to create a new Ruby instance. If I have a lot of objects, I ned to visit each one and create my Ruby version.

Instead, here is a cheaper way that simply adds the new method to the existing class

class BoringPig

# adds this method to any existing BoringPig objects or new instances of BoringPig

def flyPiggyFly

# ..... exciting stuff,

puts getName + " is flying!!!!"

end

end

Note that I don't need to fiddle with the initialize anymore. I also don't have a pointer to the object because the instance is the same. the "getName" could have been written as "self.getName", but self is implied.

To summarize, I have made a pig fly without creating a flying pig class.

Essentially I am extending the class rather than wrapping. Because Ruby is much more dynamic about when you add a method to a class definition, I can do this at any time for any reason. This could also mean that I could extend the class depending on the context and what I need to do. This is sort of like adding a visitor method directly to a class definition.

Why else would I do this? Basically I have a ton of Java in a very wordy API. I would like to reduce the churn of code to do things with these classes. For example, I have a class that has a very deep relationship that changes the classes use and context. Rather than create a wrapper for the new use and context, I can simply bubble this up to the methods of the root object. For you UML guys, I am adding stereotype info at the class rather than digging for it deep in the association of the stereotype tags.

Fun trick.

Pretty cool! This also meant my software runs a lot faster and takes a lot less memory.

Like a Ruby in a Goat's A@@

I have been programmed in Java forever. Of course, there is nothing wrong with that.

Now I am learning and writing Ruby and specifically JRuby. The reason for JRuby is that I am calling the API in MagicDraw to get some things done that I have always wanted to do, but didn't have time to set up NetBeans or 'gasp' Eclipse every few months (I am Chief Architect of MagicDraw, so always working on the latest version).

I am sure that I could be writing Java, but I just don't have the time to do the setup. That's the key. You just run the scripts. No compile, no install, no waiting. There is a lot of pull.

I am also strangely attracted to Ruby (not in that way, the platonic language loving way). A few years ago I saw a lecture by Dave Thomas (of Pragmatic Programmer fame, not the founder of Wendy's), and thought that Ruby seemed compact and a rather useful language. But alas, every attempt to learn Ruby was thwarted by the chaos which is inherent in most languages... Drifting language, few standard libraries, and poor support. This has changed with the introduction of JRuby and the inevitable tread that comes with popularity of a language... sloth.

Now Ruby's pace as a syntax has slowed. Gone are the days that you can't test the latest article or book on your latest version of Ruby. Gone are the days of trying to match the right version of Ruby with some arcane GUI library. Gone are the constant changes to the language because when something is popular, change is discouraged.

There is still change, but it is additive. The GUI can now be based on Swing and I have that one in the bag. The implementation of JRuby runs on any Java JVM, so it works on any platform. Oh joy!

Things are not all good... Ruby is an interpreted language. There is no strict typing. Errors are at best cryptic for the new user. Learning Ruby is simply cool and like torture best left behind in the Bush administration because you'll never get a proper confession from a Ruby error message.

Well, with a presentation looming, I am forcing myself. I need to talk about PRR. PRR... well it is about rules as in expert systems as in artificial (pickled) intelligence and representing said rules in UML. All well and good, but what good are rules if you can't run them? So, comes Ruby to extract the rules and run them in Drools.

Well, very quickly between myself and the great aid of Gerald Meazell, up comes working JRuby extracting UML and spitting Drools! But, then came trying to get Drools to work... I panicked... Then I looked for a rule engine written in Ruby and found Ruleby!

Ruleby is based on the great work of one of my buddies, Dr Charles L. Forgy of Carnegie Mellon University. Dr Forgy invented the Rete algorithm which is simply the reason why expert systems work because it optimized the execution of rules. I'll get into Rete someday, but take my word for it, Rete is cool.

Long story short, it is all working and I am ready for my presentation at the October Rules Fest in Dallas (except for writing the presentation... the easy part). I am using JRuby, Ruleby, and Tenjin for my template language. I can even generate a Drools DRL file!

Ruby is still treating me like a reb head stepchild, but I am learning and Gerald, who is a bonafide and card carrying red headed stepchild, is helping a lot. More to come, even some code. Got great ideas and now I can find the time to script a few.

The End of Dumb Software = The End of Dumb Thinking

Seth Godin is a marketing god. I say that because he very often exposes the obvious.

In Seth's latest blog, he talks about the End of Dumb Software. His point? Basically there is no reason for the stupidity of today's software. He is right. Sadly...

Seth's example is about the calendar app and mail on the Mac. It applies to any calendar or mail app I have ever used. There is a wealth of data, but the developers don't use it.

Many years ago I designed software that was not dumb. In fact it was what Seth is dreaming about. It understood who was important in your address book. It understood that 2am is not working hours and in fact would understand that you don't make appointments with friends and family during working hours unless it is for lunch or you were on vacation.

Where is this software? In a cardboard box in storage. Ericsson killed it. They couldn't see the utility. You might ask, how could they not see this as great? Well the VP of Ericsson I met was perfectly happy to silence the ringer on his cell phone by popping the battery off the back of the phone. In fact no Ericsson built phone had a way to silence the ringer and send a caller directly to voice mail.

That's why there is so much dumb software. Not that people are dumb, it is that they do not think. There is no analysis. It is epidemic. There should be billions of people like Benjamin Franklin, Albert Einstein, Robert Goddard, leonardo da Vinci, and other great thinkers. The problem is that most people don't explore the world with their minds. They are mentally handicapped by an inability to add two ideas together to create greater ideas.

I'll say this again and again. There are no stupid people, just a lack of people that don't use their brains and maybe never had the skills to think. People are generally lazy. It is not a degradation of their work ethic, they never had a work ethic because most people do as little as possible. That includes thinking and learning. We learn the minimum. Curiosity stops as soon as we get the information we need. The ideas stop when we solve a problem partially. Or worse, we stop thinking when a problem crops up and we don't bother to solve the blocking problem.

Smart software requires smart developers. I'll go farther and say that smart software requires renaissance thinkers. Programming and design is just a couple of your skills. Your primary skill is learning, exploring, curiosity, and invention. Then you can create smart software.

Please, if you have a pulse, please make a promise to yourself to be a renaissance thinker. Study everything. Mix ideas. Don't stop thinking at the happy path. Don't stop thinking when there is a problem. think until the problem is solved.

Ending an Argument

I found this a difficult entry to classify. I have several blogs that all deal with psychology and how it affects our decisions and beliefs. I think that computer science certainly deserves this one.

Ending an argument with a thought ending cliche sounds odd, but you have probably heard many of these if you have ever been in an argument with a software developer, manager, or customer. Simply it is a phrase that causes you to give up and not argue. It ends an argument abruptly and does not have a logical response.

Here are a few exmples:

• "That's a Good Thing"
• "Just forget it."
• "...or the terrorists win."
• "Be a man and..."
• "We all have to do things we don't like."
• "You are not being a 'team player'."

As you can see, they are insidiously generic. They could apply to anything, and that's the point. By not being specific, they are therefore false arguments.

Here is how it is defined in Wikipedia:

A thought-terminating cliché is a commonly used phrase, sometimes passing as folk wisdom, used to quell cognitive dissonance. Though the phrase in and of itself may be valid in certain contexts, its application as a means of dismissing dissent or justifying fallacious logic is what makes it thought-terminating.

The thing to understand is that when you hear these phrases, it means your opponent is unwilling to hear your arguments or your logic. In effect your opponent is unwilling to change their position.

What can you do against this? Well, not much really. When this sort of phrase is tossed out, the opponent has shut down to any discourse. Odds are they will just start getting mad or shut down further.

You can try to continue. Go for the gold! The olympic answer is that the phrase they just uttered does not apply to the specific argument. Challenge them to prove them wrong by having them utter the phrase after you state that the Easter Bunny is real or that teapots circle the Sun. Maybe it will work, but it is hard to get mental traction when someone has cognitive dissonance so strong they are unwilling to discuss a subject logically.

The best you can do is call foul (or fowl if arguing about chickens). Point to this blog and let them read it. Help them understand that they may not really have a reason to believe what they do and using a thought-ender is proof. Without evidence otherwise, you are winning and very sorry it is only because they are giving up by using such a cliche'.

Will that work? Hard to tell. Some people are unwilling to acknowledge that they are wrong. This is very strong as a past president has proven. The mind can invent many beliefs even believe these cliches' are logical and support their beliefs. The facts are, the brain is very afraid of being wrong and is deathly afraid of the cost of new beliefs.

If you can be wrong once, can't you be wrong again? The brain rebels at giving an inch because it could lead to a nasty trend.

Why fear of new beliefs? Simply being wrong means you are not a good provider and the wrong end of the genetic gene pool. If this at work, even worse. One bad belief admitted might show even more poor thinking and thus a reason why that person should be fired. As you can see, loosing an argument is like loosing a fight with a lion, proof that in the battle of the survival of the fittest, they are not so fit.

When this happens in the workplace, you need to be careful. Loosing is really bad for many people. They may already be fearing for their jobs, whether it is a justified belief or not. Leaders in companies also hate to have any questions to their authority. Programmers too are very sensitive to being wrong.

At work, you might want to be careful and defuse the situation. People are afraid of being seen as less than they are. The key thing is that we are all human. Everyone makes mistakes. I like to say in many situations like this that in some cases their may have been no other choice. Chalk it up to unavoidable and that anyone would have had that belief.

Here is the list of cliches' from Wikipedia.

Non-political examples

1. "That's a Good Thing."
2. "Why? Because I said so." (bare assertion fallacy—also “I’m the parent, that’s why” appeal to authority).
3. "That’s a no-brainer."[3][4][5]
4. "When you get to be my age..." (as in “When you get to be my age you’ll find that’s not true.”)
5. "You don’t always get what you want."
6. "What goes around comes around."
7. "The best defense is a good offense."
8. "Everyone is entitled to their own opinion." (appeal to ridicule if said sarcastically)
9. "It works in theory, but not in practice." (base rate fallacy)
10. "There’s no silver bullet."
11. "Stupid is as stupid does."
12. "Easy come, easy go."
13. "Life is unfair."
14. "Such is life."
15. "It is what it is."
16. "It was his time."
17. "Whatever."
18. "Yawn."
19. "Be a man and..."
20. "Think about it."
21. "Just forget it."
22. "...so, you do the math."
23. "We will have to agree to disagree."
24. "We all have to do things we don't like."
25. "You are not being a 'team player'." (ignoratio elenchi).
26. "That's just wrong." or "You just don't do that."
27. "It takes all kinds to make a world."
28. "Just do it."
29. "That's a cliche."
30. "That's what s/he said."
31. "Don't be that guy."
32. "Just look at me now."
33. "Touché!"
34. "Better to have it and not need it, than need it and not have it."
35. "Because that is our policy."
36. "Don't be silly."
37. "There's no smoke without fire." (used to convince others that a person is guilty based on accusation or hearsay and to discourage further examination of evidence)
38. "Your mom."
39. "But...anyways...."
40. "I'm just sayin'"
41. "C'est la guerre"
42. "Amen!"
43. "So it goes."

Political examples

Thought-terminating clichés are sometimes used during political discourse to enhance appeal or to shut down debate. In this setting, their usage can usually be classified as a logical fallacy.

1. "Racist." (Ad hominem attack).
2. "That’s just a (liberal/conservative/libertarian/communitarian/etc.) argument." (association fallacy).
3. "Socialism or Barbarism!" (false dichotomy)
4. "'Anarchist organisations', isn't that an oxymoron?" (equivocation)
5. "If you are not with us, you are against us." (or its opposite, "Who is not against us is with us")(false dichotomy)
6. "Love it or leave it." (false dichotomy)
7. "Support our troops." (ignoratio elenchi).
8. "...or the terrorists win." (false dichotomy).
9. "If you're not outraged, you're not paying attention." (false dichotomy)
10. "Better Dead than Red!" or its inverse "Better Red than Dead!"
11. "That's a conspiracy theory."
12. "Freedom is not free." (Bare assertion fallacy)
13. "Live free or die."
14. "Fascist arguments need no comments." (weasel words)
15. "If we gave it to you, we'd have to give it to everyone."
16. "Freedom is non-negotiable."
17. "Especially in this economy."

Religious examples

Thought-terminating clichés are also present in religious discourse in order to define a clear border between good and evil, holiness and sacrilege, and other polar opposites.[citation needed] These are especially present in religious literature.

1. "God has a plan and a purpose."
2. "The Lord giveth, and the Lord taketh away." Job 1:21
3. "Adam and Eve, not Adam and Steve!" (opposing same-sex marriage)
4. "God works in mysterious ways."
5. "Trust in the Lord with all thine heart; and lean not unto thine own understanding. " Proverbs 3:5
6. "Forgive and forget."
7. "That's not Biblical."
8. "Jesus loves you." (ignoratio elenchi)

The religious or semi-religious ideas of cults, heretics, and infidels are also often used as thought-terminating clichés, e.g. "Do not listen to him, he is an infidel," (a guilt by association fallacy) or "That line of thought sounds like a cult" (also a guilt by association fallacy).

Just for fun, in case you have read this far, here is a lesson on cults.

Truth in Dilbert (like we're surprised) - Diversionary tactics

I am happy to say that the following Dilbert cartoon is legitimately linked to the Dilbert.com site. I just noticed today that they allow embedding of the strip. Why am I happy? Because there are wonderful lessons to be had.

Today's Dilbert is something I see all the time. The joke here is management, but I see it from developers too. Basically imagining the worst possible outcome. Of course there is the opposite, imagining the best possible outcome.

The problem is critical thinking. Most people can't do it anymore. You need to examine critically the statements made to say it is bullshit or not. Of course it helps that the person making such statements isn't either a complete rube or has some other evil (or accidentally evil) intent.

Why would people say silly things that are either massively pessimistic, FUD but also mind blowing optimistic? Sadly it isn't because they are clueless, but they are just diversionary tactics. It is not that something is impossible, they just don't want to do it. It isn't that adopting a new language or technology is easy and spuper productive, but it is cool and would look good on a resume.

Remember the old saw: Don't assume malice when simple stupidity will do. Well, here is another one: If they really aren't that stupid, there is another reason why they 'sound' stupid. Sadly this 'sounding stupid' is pretty deep. To say something stupid, you have to commit to believing the statement. That means endless argument as facts will be ignored.

The human brain is a messy place.

On to the cartoon!

Check Your Blinders at the Door

Here are some bad words:

• Tunnel Vision
• Blinders
• Arrogance
• Single Mindedness
• Happy Path
• My Opinion
• One Way
• One Solution
• One Method
• Only

These are very bad words because they all lead to software failure. Simply they lead the developer into false beliefs that the code is complete and meets user needs.

• Think like a user, not how you would use it!
• Happy, Unhappy, Alternate Paths
• What could go wrong?
• Can the user make a mistake?
• What about Undo/Redo, s the action symmetric?

Remember that the most critical bug is that the user will not use your software. If you cause extra work for the user, inconvenience them, waste their time, or treat them as stupid drones, you will not be considered a great programmer.