Personal tools
You are here: Home Python About Python World
Document Actions

About Python World

last modified 2006-02-22 03:49 PM

Python, Scripting and FourM

I never took a degree in software engineering or programming. When I was in college, "computer science" was mainly about building computer hardware and taught only in engineering schools.

I took one Fortran programming course at Columbia Engineering (Columbia College undergrads could take courses in other University schools) and I loved it. At the time students still used punched cards to submit their jobs. Terminals were available for advanced work. In my first ever act of hacking, I figured out the username and password for the music department (music, music) and voila, I was able to type my programs on a terminal and forgo punched cards! One day the professor came into class and mentioned how something really strange happened - the course had gone through its' allocation of computing time (in those days computing resources were scarce so classes were given "budgets" for how much computer time they could use). He noted we received a new allocation and asked us to be more circumspect in our computer usage. I felt like hiding under my chair since I knew I was the culprit. I didn't touch the terminals for the rest of the semester.

I went on to graduate school at Carnegie Mellon's School of Urban and Public Affairs. SUPA puts a great emphasis on analytic methods of management (mostly useless I would say) and so computer use was greatly encouraged. At the time CMU was a big DEC-20 place, and we had basically unlimited access to the computers through the plentiful terminals scattered all over the campus.

This is where I first learned about how much fun computers could be. Besides spending hours playing Adventure (I even took my wife to play at the computer labs as a cheap date), I also was exposed to such interesting new programs as Emacs and Scribe. I learned about technology, and took a couple of computer courses (including one on database systems), but I was far from being a programmer.

When I graduated CMU I went to work at Arthur Andersen's consulting practice in Philadelphia (many years later this practice was spun out from the accounting side into a company named Accenture). AA invested 3 months in every new recruit for training, including a 3 week stint at their Chicago training center. There we learned how to program in IBM 360 Assembler. I kid you not.

With that training I was now qualified to be a programming analyst. AA was developing some structured analysis method of its own, which we also were trained in. But frankly, in the year I worked at AA, I didn't do any programming at all.

While at AA I decided that what I really wanted to do with my life is be a programmer. One day while attending a seminar on databases (paid for by AA) I heard this man named Dave Root give a talk about his company International Database Business Management Systems (later to be called SEED Software). And so I walked up to him and to my amazement, a few months later I was working at IDBMS' research & development department.

Now here's a guy that didn't know shit from Cheyenne about programming, working in the R&D department of a major DBMS development company. That happened all the time in the early '80s since there really weren't very many computer science graduates floating around.

My first major assignment was to build a parser for a new report-writing language we were adding to the system. I panicked!! What the hell did I know about parsers? I didn't even know what a data structure was or a linked list, let alone what lexical analysis is. I didn't know anything. And we were writing this in Fortran, to boot.

Fortunately I was a fast learner and I was in a room with 5 other extremely smart, extremely talented and extremely friendly programmers. With a lot of help from my friends, I built a very simple table-driven parser. I don't know much more about parsers today, except that there are great Unix tools that let you build parsers much faster than I did. But somehow it did work and it was very straight-forward and easy to read code. Maybe not the fastest thing on the planet, but it wasn't going to be a speed block in our system. I was pretty proud of it.

Shortly after completing it, the president of the company decided that he wanted to set up weekly programming meetings (this lasted about two weeks) for code review. To my chagrin, the first project we were going to look at was my parser. I gave my presentation and el Presidente proceeded to rip me to shreds for not using more sophisticated techniques. I didn't even know what he was talking about. Fortunately my colleagues came to my defense, arguing that for the job, my solution was the simplest and fastest solution (in terms of programming time, not necessarily speed of execution).

After a year at Seed, I left to become a software consultant in preparation for my move to Israel. It was mainly setting up DBMS for hospitals, using a Unix -based system developed by a good friend. Great pay for easy work. It was actually my first exposure to application development using a scripting system.

My first job in Israel was a hard core programming job (again in Fortran) developing a CASE tool. That lasted a few months before they started sending me around the world trying to sell the tool.

From there I moved into system administration work in a software startup (that made an interesting CASE tool that is actually useful). I quickly moved into a senior management position, and then moved over to the world of international sales and marketing.

I tell this long story to point out that I never really had formal training in computer programming and I didn't spend many years as an actual programmer. Over the years I have learned quite a bit about software technology and development, especially as a software project manager. I managed some very sophisticated software projects large and small, including in my own software company, for the past ten years. Despite my early programming jobs, I would never call myself a programmer. A scripter, perhaps. But not a programmer.

One interesting change in the computer world over the past 30 years is that the ratio of scripters to programmers has changed significantly. Once, most applications required hard core programming. Only simple applications could be developed using scripting tools and languages. Third generation languages, including those we developed at SEED Software, began to change things. The advent of the personal computer and tools like Visicalc and dBase (then later Excel and Access) began to accelerate the change. The rise of the Internet and the use of PHP, HTML and content management tools flipped the ratio completely. Today, the vast majority of programming applications are developed by scripters, rather than programmers.

Of course, the lessons of good software development methods are equally important for applications developed by scripters. Unfortunately, many scripters take a slap-dash, amateurish approach to application development. The results can be seen all over the Internet and inside many corporations.

Which brings us to Python. Python is an amazing programming platform that can be used in a broad range of applications, from the simplest scripting to the most sophisticated programming development. Within my own company we moved to Python many years ago. First with the adoption of Zope and then much later with Twisted and general development.

Powerful tools like Python, embodied in Zope as well as Plone (the tool I used to create this site), allow scripters to develop extremely sophisticated applications relatively quickly and with great sophistication. But you still need be a good scripter, and you still need to call on a good programmer to extend and enhance the tools you use.

Scripting really fits in well with the ideas of FourM: build it fast, and then refine and iterate with customer input. What that means is that a project manager has to be hands on - taking the specification directly into the working application, bringing in more sophisticated craftspeople where appropriate in the life cycle. The days of writing specifications and handing them to programmers are fast disappearing for many types of applications. Now the manager can script the main part of the application, and then hand-off appropriate parts. This means that project managers, like me, have to spend more time learning scripting languages and tools.

Which brings us, finally, to this section of the FourM website. Here I will talk about my learning experience, mainly with Plone and Python. Unfortunately, most of the resources available for learning about these are targeted at programmers. So this section will be a place where my fellow scripters can learn from my experience (in Oscar Wilde's sense: experience is what we call our mistakes!)

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: