User Interface Design

We had a new developer design a couple screens for changes in our application. He had a couple busy screens. Sure one of the screens was dictated by the customer. But the other one was a monster that he created himself.

When we did a review of the design, I pointed out that there were way too many buttons on the screen. The new guy explained the use of each of the buttons. I determined it was time to step back and figure out what our goals were.

The top goal should be to make the most common operations easy for our customer. After that, the screen should be intuitive enough that you don't have to read a manual to figure it out. The design for this one new screen was not achieving any of those goals. What happened to the good old Windows user interface design principles? It might be time to get back to basics on our project.

Bulding Robust Systems

There are many principles you can employ to design systems that don't break often. This will help you sleep better at night. That is because the system won't crash, and they won't have to call you for help. I should know about this. I just got a support call this evening. We must not be following the right principles at work.

One this you can do is to manage your events with a queue. There is standard technology to deal with queues. An example is Microsoft's MSMQ. You can even choose a queue in the cloud if you want to get fancy. Wait. Hold that thought. You do not want the support calls. So choose a mature and stable queuing technology.

Many business processes are batch oriented. Each stage requires the output from the prior stage. Our back end is a big UNIX system. You would think you could just pipes the processes along. That works in theory. This is a bad practice in reality. You should design a scheduling system that spawns the processes separately. The results from each stage should go to a file. The scheduler can wake up every so often, see if a stage has completed, then start up the next stage. We have our loading software follow this pattern. It is rock solid, even when things go awry.

A final tip is one that I have heard before. Every time you resolve some trouble ticket, you should turn that into an additional automated unit test. You already are investing the time to test your bug fixes. It is a marginal extra effort to automate that testing. This helps you grow your unit test code base and coverage. Sometimes prevention helps you avoid the pain that you would get otherwise.

Scrum and DSDM

A magazine article I read recently reviewed different agile software methodologies. I have previously written about Extreme Programming. Now I will go over Scrum, and a new one I am not familiar with (DSDM).

Scrum is a management technique. One of its goals is to stabilize requirements. That alone is a noble goal. I find our requirements lacking in general. However Scrum also advocates a daily stand up meeting. Those I have found degenerating into a waste of a whole lot of time.

DSDM stands for Dynamic Systems Development Method. Have you ever heard of it? Neither have I until now. It attempts to hold the resources and delivery date constant. The way to achieve that is to modify the scope of the deliverable. I like the sound of that. It comes from Britain. I don't think it is popular in the States.

I will have more later on things like Continuous Integration and Test Driven Development.

Agile Methodology

I got a really good overview about Agile Methods from a magazine I read this weekend. Surprisingly it was a magazine on testing. It seems the techniques have progreesed past plain development to the world of software test.

Let's start with the first, and what I consider the biggest. That's XP which stands for Extreme Programming. It sounds funny when applied to testing. XP was created by a guy working for Chrysler.

XP focuses on delivering small release quickly. Then you can circle back and add more functionality in later releases. That has the distinct advantage of getting something done fast. It also provides a tangible program for the user to try out. You can get some great feedback from such a responsive development cycle.

There are a number of techniques used in the XP world. These include Test Driven Development (TDD), Pair Programming, and Refactoring. Perhaps I will go into these techniques at a later time. In the mean time, I plan on explaining Scrum and a new method called DSDM. Later.

Programming Rules

I read an article on the web by Rob Pike. He is an important guy in the UNIX/C world. I know I own at least one UNIX text authored by him. For some reason, I thought he was also one of the authors of the awk scripting language. However that does not seem to make sense as the letters in awk are supposed to represent the first letter of the last names of the three guys who invented the language.

It seems I digress. The article I read was entitled “Notes on Programming in C”. The funny thing is that many of the topics discussed by Pike are not specific to C. They can be applied to most programming languages. That is kind of like a Code Complete by McConnell. Let’s start with some of the C specific items as they are few. One is that you should not include another file within an include file itself. In other words, you should not nest include files. Another tip was that pointers are preferable to objects. I think that means pass pointers to objects instead of making copies of the objects themselves.

Now let’s move on to some of the guidance that can be applied whatever programming language you are working with. The first is the short variable names are often better. For instance, it is reasonable to use the variable i for a loop index variable. Next you should strive to eliminate comments. This may sound contrary to what you were taught when you first started programming. However the best code is clean, simple, and easy to understand on its own. It does not need to be littered with comments. This eases maintainability. You can also trust the code always. Comments that are wrong or misleading are harmful.

Finally let’s talk about procedures and functions. Procedure should be named according to what they actually do. That sounds simple. But you would be surprised how some procedures are named which have nothing to do with their function. Next you know that a function returns a value. You should name the function based on the type of value it returns. Any functions returning a BOOL should be in the form of a question. Examples of this are isOpen() and canDelete().

More Object Oriented

Some time back I went back over a textbook I had from my Object Oriented Analysis and Design class. The book was authored by Grady Booch. The title of the book was Object-Oriented Analysis and Design with Applications. I have covered some ideas from this book in previous blog posts. This time I want to finish up some topics I read in the book.

A very popular term within the OO world is polymorphism. This means one name with many implementations. In other words, you have multiple related classes with the same function name. Then depending on the object upon which you are calling the method, you will get the right implementation executed.

There is another scenario where you have the same function name, but multiple implementations. This is where you have multiple functions within the same class that have the same name. However they are differentiated by the number and/or types of parameters that are passed in to the function. The official name for this behavior is overloading.

Another key idea in OO is that of aggregation. This is a big word to say that one object has another object or item as part of it. A synonym for this idea is containment. There are some lesser used OO topics that Booch mentions. One of them is that of a meta class, where the instances of the class are classes themselves. That does not sound familiar from my experience.

Some techniques for performing object oriented analysis and design are use cases and CRC cards. I have only hear about but never participated in CRC card analysis. Apparently you get together in a room and write down things on physical cards. I have done a lot of use case work in the past. However these days we skip that during out analysis phase. So do our requirements people.

Finally I read up on parametrized classes. These are classes whose behavior depends on parameters passed to the class. In C++, this idea is implemented as templates. I do have a little experience with templates in general. However I believe I want to beef up that experience.

Object Oriented

Some time ago I reread an Object Oriented Analysis and Design book by Grady Booch. It brought back a lot of memories from my first college class on OOA. So I thought I would talk about some more main topics from this book.

As far as programming languages go, the two ends of the spectrum are static binding and late binding. Most languages may one or the other. However a language may fall between the two extremes. Static binding is where variable types are fixed at compile time. It is also called early binding.

Dynamic binding is where variable types are not all known at compile type. This is also known as late binding. Having just completed an introductory class on Java, I now know that Java is a language with dynamic binding.

Why do object oriented modeling anyway? In theory, it encourages reuse of design. It also allows you to build upon components which are already tested and known good. Furthermore, some of the object oriented outlook feels nature to people. Evangelists say that Object Oriented Programming gives you great power. I am not so sure about that claim.

Let’s wrap up by defining some important terms in OOA. State is the properties of objects, along with the current value of those properties. A class defines a common structure and behavior for objects. And cardinality refers to the numeric relationship between classes. For example, a car has four wheels.

Next time I will go into big topics such as polymorphism and aggregation. Again this all seems very relevant as I just learn Java, which is an object oriented language.