Development Estimates

There are many difficulties in estimating how long a software development project will take. You cannot compare estimate for small systems to those of large ones. The rate of development is not linear as the project size goes up. It just does not scale.

Another common fallacy in estimates is that developers spend the whole day coding. You will be lucky if they get to spend 50% of their time in development. Productivity also depends on the task complexity. Expect to get around a thousand lines of high level code a year per developer.

Here is another tragedy. Sometimes when a developer just tries to get their part done, it is to the detriment of the overall project. Want to hear more depressing news? The first system built is hardly ever a usable one. Next time I will continue with ideas about design and development.

The Power of Documentation

It is best if your user manuals are accurate. Choose this over exciting text. It is difficult to be exact. The spoken English language does not lend itself to written clarity. Know this. When there is some discrepancy between the system and the documentation, it is easy to fix the documentation.

If an implementer has a problem understanding the design, they should get on the phone and call up the architect. I know I get calls all the time on stuff I design. This is natural. It is better to do this than to guess and get it wrong. By then it will be too late or too costly to resolve.

A rare combination of skills is the technical guru who can also do project management. However if you can find one, it is best if they manage a small team of about 5 developers. This team will have great productivity and success.

Next time I will share a lot of pitfalls with scheduling estimates.

Model Driven Software Development

I read a book from 2003 on Model Driven software development. Let's first define what we mean by model. A model is an abstraction. It is cheaper than a real system. The problem is that models are not kept up to date with the code.

MDSD stands for Model Driven Software Development. It is also known as MDD. Right now models are just treated as documentation. However in MDD, models are at the same level as code.

A related topic is MDA, which stands for Model Driven Architecture. This is where you focus on UML to do design. UML produces nice looking documentation. Some problems that plague software development are productivity and risk management. MDSD intends to address these shortcomings.

Next time I will start with the hot topic of Domain Specific Languages (DSLs).

Airplane Experiment

Let us imagine an experiment. We transport some engineers from the 1890's to the present time. Then we give them a ride on a 747 airplane. After that they return to 1890. Having experienced flight in an airplane, they now know it is possible and want to build some planes in their own time.

This is problematic. The engineers recall the heavy metal bird from the future. So they conclude that weight is not a problem in propelling planes. They also fondly remember the plush seats inside the plane. The engineers design that into their primitive 1890 plane. Finally they recall that steel was used extensively in the 747. They take their own 19th century steel, and try to form an airplane. The result? Fail.

The whole exercise is to get you to understand how an observer of something that works does not necessarily gain the deep knowledge required to replicate the technology. The same probably holds true for Artificial Intelligence. You can study an intelligent being like man. However that does not mean you are any further in developing AI. In fact, you might be tripped up by your limited understanding and go down the wrong path. You got to take those baby steps like the Wright brothers. Otherwise you may never even get off the ground.

The Chinese Room

Here is an artificial intelligence riddle of sorts. There is an English bloke locked in a room. There is room enough under the door to the room to slide a single sheet of paper. The guy frequently finds papers shoved under the door.

The papers the guy in the room receives has strange markings on them. However he has a big book in the room. The book provides instructions on how to formulate responses to the papers that come into the room. The English gent follows these instructions to the tee. He composes similar sheets with weird markings in accordance to the Book of Knowledge in the room. He then slides these response papers back under the door out of the room.

On the outside, there are a bunch of Chinese scholars. They pose tough questions written in the Chinese language to the guy in the room. They write their questions on pieces of paper in Chinese. Each of them is amazed at the answers that come back out written in perfect Chinese. These scholars presume that a great Chinese scholar is on the other side of the door in the room. However this guy does not speak or read Chinese. He just follows the instructions from the big book.

Does the room speak Chinese? Or more specifically, does the system know as the room know Chinese? If it does, you probably could concoct a computer that thinks using a similar process. Once you know what is behind the code used to run the program, you will know that the computer can't think. However from the outside, it would be difficult for one to tell the difference. Such a computer program might be able to pass the Turing Test.

Computer Chess

You would think it an easy task to get a computer to play chess. That might be true. But it is not easy to get the computer to play chess very well. Perhaps chess is not just some mathematical equation to be solved.

True you could have the computer consider all kinds of future moves. The processing power helps with this task. However there are just too many computations to do this in real time.

The next best bet would be to get a computer to learn how to play chess well, almost like a human would do. Well IBM put its programmers to the task. The produced Deep Blue, which took on the world's human chess champion.

The programming behind the scenes with Deep Blue could occupy a whole book. Here are two tidbits. The computer program evaluates the situation of the chess board for every possible move. To speed things up, the program prunes off poor decisions from the tree of possible future moves. This helps it spend time "thinking" about the best moves.

Next time I will tell you a riddle about The Chinese Room.

The Real Turing Test

The original Turing Test is a little different than I normally hear it described. It starts with a man, a woman, and an interrogator. They communicate using text. The interrogator tries to determine which one is a woman. The man impersonates a woman.

The trick is that the man is then replaced by a computer. Now the interrogator tries to determines which of the two (computer or woman) is the computer. It is a test of how well the computer can simulate a human.

There is an annual contest to see whether new computer programs can pass the Turing Test. The best attempt wins $2,000. And if any program can actually pass the test, they win $100,000.

Next time I will go into other artificial intelligence topics such as a computer playing chess.

Artificial Intelligence

I went to the library and picked up a book on Artificial Intelligence. This book was written with the general reader in mind. It made no assumptions that you knew about AI, or that you were a technical person.

Some people in the AI field have made a lot of money in the commercial sector. If you really want to learn AI, you should first learn programming.

I have heard about the Turing Test before. You put a computer up against a human, and see whether a third observer can detect which one is the computer. However this book helped provide a lot more insight into the history and current attempts at winning the Turing Test.

More on this delicious book later.