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!