A wonderful emotion to get things moving when one is
stuck is anger. It was anger more than anything else that had set me
off, roused me into productivity and creativity.
Mary Garden Read more at
Brainy Quote
America's growth historically has been fueled mostly
by investment, education, productivity, innovation and immigration. The
one thing that doesn't seem to have anything to do with America's
growth rate is a brutal work schedule.
Fareed Zakaria Read more at
Brainy Quote
1970 Programming Productivity
When I first started to learn to program computers in 1970 I was 12 years old, taking the Vancouver School Board's first Mathematics Class with computer programming added to the curriculum, my Productivity was very very very low. This had nothing to do with the fact I was 12, or the fact that I was learning to program computers for the first time - it had everything to do with the methodology, technology, and science I was using.
Methodology
In those days the methodology was that before writing any code, you had to first create a Flow Chart of the problem you were going to solve. This was fun at first because it meant drawing boxes on paper with lines and arrows - especially fun when you are 12 years old and like to draw. After I few months I had my first real argument or debate with my favorite mathematics teacher. I stopped creating Flow Charts and simply started writing the code. I argued that Flow Charts were unnecessary and he argued they were necessary. The argument was settled when I realized that already I was a better programmer than my teacher, and that the Flow Chart was for his sake not mine, and without the Flow Chart he could not understand my code well enough to grade me. It was like writing in the answer on a math test, without showing how you got the answer. The original debate would not have been so protracted if he had simply stated the fact up front that I was already a better programmer than he was. One other thing, our school was very good at forcing students to come up with their own life realizations - and I thank them for it.
What I want people to appreciate is that writing Flow Charts in no way increased my personal productivity, in fact it lessened my productivity by taking my time away from just writing code. A key point here is that if you have to keep stopping to explain things to your teacher or boss, you become less productive. Imagine if your boss has 10 people reporting to them, and they each have to spend 10% of their times explaining what they are doing for the sake of their stupid boss. You now have one whole less person of productivity. Can you appreciate now why Scott Adams' Dilbert cartoons are so enormously popular. The solution to this problem is
- Get a smarter boss who knows what you are doing.
- Get a more trusting boss who trusts you know what you are doing.
- Get a more effective boss who knows when you do not know what you are doing, and gets you the training you need so you are both confident you know what you are doing.
The bottom line is that methodology is a key pillar of productivity, and that everyone needs to be on the same page and trust each other to be on the same page.
Please don't take away from this that Flow Charts are not important, because with very large complex projects they do become important, and methodologies like Universal Modeling Language are used to articulate that complexity.
In those days the technology was that you would need a really good pencil, and would use it to write you program on Optical Mark Cards - each card was one line in the program. This was very tedious, mistake prone, and time consuming. When you assembled a deck of cards with your program you would wrap it with a piece of paper (that had your name on it) and a rubber band. You would put that in a box in the corner of the classroom. At the end of the day, the School Board delivery truck would pick them up and take them to one of the three schools that had a computer. They would run the deck of cards through the card reader, and them re-wrap them with the output from the printer and your name, and send it back to my school. If I was lucky I would get the results back the next day, but more often it was two days later, sometimes more. Given that 12 year old children want instant gratification, I was intensely patient to put up with this for years.
Once a week I took the bus in the evening to spend time at one of the high schools that physically had a computer. Given I could now put the cards in the card reader myself and get the printout instantly, and assuming it still took me 10 minutes to write a program on cards, I was then 288 times as productive as before - given on average it took the school board 2880 minutes to turn around my programming experiment with the delivery truck.
In reality, I would never send just one programming experiment via the delivery truck, but I want you to appreciate how the right tools and technology affects productivity.
On quiet nights, sometimes I was the only person and I could use the teletype connected to the computer, instead of using optical mark cards. Unless you have used optical mark cards, you would not believe how much more productive it is using a keyboard and getting instant feedback from the computer when you make a mistake. I would have to say, in this mode, my productivity was 10 to 20 times more than marking cards and putting them through the card reader. It was also way less wasteful of paper.
The key concept here is how productivity is related to the technology workers have available to them. If organizations want increased productivity, one way to do that is by investing in better tools and technology.
The bottom line is that technology is the other key pillar of productivity.
Science
10 PRINT "Enter a number to see the factorial"
20 INPUT N
30 LET F = 1
40 FOR L = 1 to N
50 LET F = F * L
60 NEXT L
70 PRINT N; "! = "; F
80 PRINT "Would you like to see another factorial? 1=YES ANY(other)=NO"
90 INPUT RESPONSE
100 IF RESPONSE = 1 THEN GOTO 10
110 PRINT "Thanks! Goodbye."
120 END
In those days my first programming language was BASIC or Beginners, All-purpose, Symbolic, Instruction, Code. Pretty much all of the Computer Scientists and Professionals I respect these days ubiquitously agree that BASIC is one of the most horrible programming languages ever devised. In the early days of computing, there were a great many mistakes and failed experiments made, and BASIC is just a failed experiment.
Some people might say that BASIC is a technology and not a science, but my point is that really good computer languages are designed by Computer Scientists, and the best languages are designed by the best scientists.
Now if all you are doing is writing a 10 or even 100 line computer program, then BASIC is not all that horrible. For example, if you are only building a one floor building, then mud and straw is not all that horrible either, and is really inexpensive and expedient. The questions is, would you feel safe on the 100th floor of a building made of mud and straw?
There is an old joke that if Engineers built buildings the way Programmers built programs, then the first woodpecker to come along would destroy an entire city. Quite literally, most computer software these days is very much like a city built of mud and straw. The failure of software developers is not always that they do not know how to write software, it is that they have not learned to educate their bosses yet that software developers need more than mud and straw to build with.
To be sure, when my card decks started getting over 100 cards, understanding and changing the program became exponentially more difficult. I am not feeding you hyperbole either; managing 100 cards is not 10 times harder than managing 10 cards, it is more like 100 times harder.
Since then, Science and Engineering have given us programming languages far better than BASIC. What is really sad is that Bill Gates, who was not a scientist, promoted BASIC and ultimately created Visual Basic; a curse upon the world the way Typhoid Mary spread her curse upon the world. Mary was scared, selfish and ignorant, and did not care to listen to anyone else about how dangerous her affliction was.
The key concept here is that the science of program organization and management allows us still be productive when managing a million or ten million lines of code. If you are not using the best science, then you cannot be as productive when trying to comprehend and manage those really large sophisticated programming projects. You cannot be as productive as possible if you do not understand or use the latest science and engineering.
The bottom line is that science is the third key pillar of productivity, and without three legs to stand on, productivity will fall over. In particular, science and research is critical to process improvement, and productivity is inherently about process.
2013 Programmer Productivity
Methodology
When I was a snively-nosed teenager there was not a lot of methodology, when I started there was (1) draw the Flow Chart, (2) write the code, (3) test the code. Even when I was in University there was not a lot methodology that was taught, primarily because I studied in Computing Science schools.
Finally people started applying a lot of Engineering Methodology to software development and we got Software Engineering. Over time, Software Development Methodologies evolved into the abilities for huge teams of people to create software systems of stunning scale and complexity with increasing productivity, reliability and safety.
It is still true that if Detroit built cars the way software companies built software, there would be 100 times as many car related deaths, and 1000 times as many car related injuries as there are today. It is very telling that almost every software product on the market includes a disclaimer along the lines of: We make no claims that this software does anything correctly or useful in any way whatsoever; please enjoy it.
To be very clear, there does not yet exist any legal concept of "software consumer protection." On the other hand, as methodology improves, so does the ability to make safer and more reliable software. What is abundantly clear is that evolving and improving methodologies are increasing productivity.
Technology
Technology is the main reason that one factory worker can produce a million times more widgets in the same amount of time as a single artisan hand crafting said widget. These days I use technology like Integrated Development Environments on high performance workstations with 30 inch computer displays; Virtual Machines that let me simulate dozens of different operating systems in dozens of different configurations; automated tools to manage the methodology and processes of developing software.
These days I work on systems that are the equivalent of a deck of optical mark computer cards that have a million cards in the deck. Technology is quite literally the ability to do things you were never able to do before.
Science
Over 40 years I have generally been able to quickly pick up new programming languages. Some of them were horrible and hard to learn, like COBOL, and resulted in poor programming productivity. Others, like Pascal, were simple, elegant and easy to learn, and productivity for a student learning to program was quite high. Students can also learn to program quickly in BASIC, but they learn so many bad habits, afterwards their overall productivity can suffer for years or decades to come.
By 1995 Java came on the scene. It was influenced by languages such as C and C++, and platforms like UCSD Pascal; it applied better science and design, and made programmers dramatically more productive than C and C++. One way to demonstrate how effective Java was at increasing productivity is that Microsoft were forced to shift away from C++, ATL and COM (the three pillars of programming hell) and create C# and .NET, which is pretty much an exact design copy of Java.
After 13 years of using Java my overall productivity increases are slowing because the Java language is not keeping up with Computing Science. These days I am struggling to learn Scala, but already I can see the path to being more productive. I say struggle because Scala is based on so much new science I did not have in university, or have not kept up with in my professional career, I struggle to catch up with the science now. What is important to realize is that in almost all aspects of productivity improvements there is always some kind of investment to make, and there are many dimensions to the kinds of investments.
Astronaut's View of Productivity
We have come a very long way in over 40
years. Everyone is keenly aware of the advances in electronics that took
us from vacuum tubes, to transistors, to integrated circuits. Fewer
people are aware that we have pragmatically reached the limits of how
fast electronic circuits can operate. Computers are not getting any
faster. Computers are still getting more powerful, though, because they
can do more work in parallel with more circuits. Unfortunately the
science of writing parallel software has not kept up with the pace of
building parallel hardware, but it does continue to progress and get
better. In essence, while computers will not get any faster, they will
seem to get faster by making computers multitask more.
As
an aside, there is a class of problems that cannot be reduced to
parallel computations, and consequently computers will never be able to
solve these problems faster. For example, most people will realize that 9
women cannot make a baby in 1 month, but they can make 9 babies in 9
months.
Often I have seen on Job Postings "Good multitasking skills required." This is a sure sign that management expect their employees to function like computers or robots. To be sure, people can multitask on some things quite well, like walking and chewing gum, but we are horrible on many other things, like making a single baby, and our overall productivity drops significantly when we try to multitask on many things
In particular, when multitasking, productivity should not be measured in how many widgets per hour can be produced, but in how many widgets with zero defects per hour. Or if you are only producing one cool widget that people can just download to their phone or tablet, how much technical support staff do you need to satisfy your customers before they get pissed off and go try some other company's widget? Isn't it just more productive to build a widget that is so simple and effective that it does not require a huge dedicated support team?
The bottom line, when discussing productivity, is how are you measuring productivity? When increasing productivity are you measuring it before and after you increasing it, and weighing that against your investment in increasing productivity?
All I am saying is that the world of productivity looks a hell of a lot different from orbit, than it does from the parking lot behind some building.
