Image1
Michael
Marking’s
Web Site

Software

 

 


Home

Start Here

Bionic Buffalo
Buffalo Bull
Economics
Engineering
History
Languages
Law
Mathematics
Philosophy
Politics
Religion
Reading
Reviews
Software
Writing

Other
  Trademarks
  Public Keys
  Licenses
  Social Media
  Contact
  Web Site
    Information

What's New

 My Background

Computers and things related have been my vocation for over forty years. Most of my projects have entailed designing and developing software, but I've been fortunate to work close to the hardware a lot of the time. It has been almost a continuum from real-time and embedded systems to operating systems to networking, often with an emphasis on security. My work has gone into aircraft, factories, machines, tools, peripherals, consumer electronics, instrumentation, telephones, radios, and automobiles. I've helped make chips, and the machines that make the chips.

Sometimes I would get a proper specification for a job, but at other times all I'd get was a schematic or some handwritten notes, or maybe just the manuals for the other components. Sometimes, all there was to work with was a set of blueprints, or equations or control charts with expressions written in s-space or z-space. In the beginning, UML hadn't yet been invented, never mind SysML, but even after it was, most the systems guys don't think in those terms, and they're inadequate for complex systems, especially for those with analog aspects. Sometimes they'd just draw out a circuit diagram, and say, “I want a program that does what this circuit would do.” So sometimes, I'd have to draw my own schematics, hand it back to them, and tell them I needed a few changes to the system, adding an op amp here or an A/D converter there.

For almost all of my career — which is now almost all of my life — I've worked on projects, on efforts more or less operated for the purpose of creating specific end results (though perhaps only vaguely understood or defined), rather than, for example, as a manager of some portion of an enterprise. Someone else can act as a shepherd for enterprise resources; I'd rather build products or investigate problems or challenges. A “project” need not involve a product: fixing a bug can be a project.

Along the way, I often had to develop tools where there were none. I wrote compilers and debuggers and network traffic analyzers, and even whole operating systems, when unable to find what was needed for the job. There was some porting, too, it being at times easier to re-code existing software or operating systems than to create a new one from scratch. A few times I had to create code for CPUs or other hardware, before the hardware existed: the team designing the hardware was working in parallel with the software developers. We had programs, but we didn't yet have a computer.

Some Observations on Software Development

Times have changed. Even popular news occasionally notes that the cell phones of today are more powerful than the giant mainframes of yesteryear, that networking is a billion times faster, and so on. But they don't much talk about what has happened with software development. Forty years ago, we were building almost from scratch. Now, we're using billions of lines of library code and incredibly complex operating systems and programming languages which are astounding developments in their own rights. It's true that we're now creating applications barely imaginable only two generations ago, but that's missing the point that we're working with tools, with raw materials, and with knowledge that didn't exist back then, either.

This change in the way we work has both good and bad consequences. The best part is that we can build things we couldn't build previously, with less cost than it once took for simpler systems. But there are several adverse results, as well. Perhaps the worst part is that it's harder to think outside the box, when you're not building your own boxes. And there is also a sinister side to this, in the way businesses and projects work: companies hire “skill sets” as much as they hire people. The development environment has become less human, as the developers are more often viewed as tools with certain characteristics, rather than as people. Creativity is stifled, and the products look more and more alike. Not every project requires software innovation: the world isn't always about computers. But, when it does and is, you're not going to be differentiated from others when you're using the same components, and hence the same constraints, as your competitors.

There is a serious shortage of innovation and high level design in most of the development efforts I run across. That’s not necessarily the fault of the people doing the work; it’s often the result of management which has little understanding of the engineering behind the product. There is often little correlation between engineering quality and technical excellence, and profitability: often the lowest quality products are the ones which survive in the marketplace or in a firm. Innovation is equated to risk, so we get less innovation. This situation frequently is found at the highest levels. For example, “artificial intelligence” is more artificial than intelligence: we create more and more elaborations on a few basic algorithms, but there is very little work done trying to understand thought itself. Much of the time, even the big, splashy projects are little more than brute force approaches to solving problems. A plethora of programming languages dance around the algorithms, and a lot of the programmers have only a shallow idea of the greater context.

More than once I’ve seen two teams of about the same size, just down the road from each other. They both work on code bases of about the same size and complexity. Team A spends 80% of its time doing new development and 20% of its time fixing bugs; for Team B, it’s the other way around. The code for Team A is clean, well documented, and efficient, while Team B has little documentation, is plagued by bugs, and has accrued massive amounts of technical debt. Who is successful? Often, against all obvious logic, Team A fails (their company goes bankrupt or their project is cancelled) because of forces unrelated to the engineering effort, while Team B continues to waste huge amounts of money despite their problems.

Some of the best managed projects are to be found in companies which aren’t primarily “tech” or software firms. In such cases, the work is done for in-house consumption, and there is a lot of transparency in operations and in development. There is less effort put into fooling the customer – the developing enterprise itself is the customer – and more effort put into getting it right. On the other hand, the much ballyhooed Silicon Valley and other “high tech” success stories are quite often houses of horror on the inside: they don’t have high stock prices because of their engineering prowess, they succeed for other, uglier reasons.

In almost every case, I’d rather work with a small team of experts than with a much larger team of developers and engineers. Studies done decades ago, and confirmed repeatedly since, show that the best developers out-produce by several times the “average” developers. Being skilled in some programming language or environment or having experience with a certain methodology is great, but it isn’t worth nearly so much as a good, practical knowledge of how basic components – compilers, operating systems, databases, and so on – work inside and together. In a good team, no one is considered a god: I’ve worked alongside some of the best engineers, mathematicians, and other experts in the world, many who have been known and respected throughout the industry (some wrote the standard textbooks for their fields), and the best ones in practice are the ones who roll up their sleeves to pitch in like everyone else, and keep their office doors open like everyone else. The best ones haven’t lost their love of their work and for their subject, and are willing to share what they know. They’re not afraid of competition, because, within a team, it’s not about competition. When they get big heads, it’s time to get rid of them, not time to pamper them.

Current Projects

I'm currently working for Ulterior Logic, a company I helped start to act as an umbrella for some of my projects. Go there to see some of the things we're working on. (I'm sometimes farmed out to third parties; if you're interested in having me work on a project, then let me or Ulterior Logic know.)

Although I enjoy mathematics, I don't get to use it often enough on the job. Fortunately, one of my Ulterior Logic projects is coyotemath, a math problem solving tool which has forced me to brush up on topics in mathematics I haven't touched in years. It's a fun project.

Another project transferred to Ulterior Logic was sysjinn, a family of tools to assist with routine and tedious coding tasks. ⇒ More information...

I've kept some active projects to myself, however. Among these are:

cl-manpages: Man pages, in troff and in html, for Common Lisp, for the language itself and for some useful Common Lisp packages. ⇒ More information...

oloman, a set of scripts to convert OpenOffice and LibreOffice documents into troff for *nix manpages. It's done with styles: the scripts recognize certain styles and convert the styled text appropriately. ⇒ More information...

htdex, a program to locate all of the html files in specified directories, and then to build an index page. The idea is to find the html documentation for software packages, which has no standard organization. Where is the documentation for X? This, I hope, will make that documentation easier to locate.

I was one of the last among my colleagues to get a personal computer, a PC. At work I had lots of computers, so why did I need one at home? When I did finally get my own PC, one of the first pieces of software I bought for it was a Lisp development environment. Lisp, along with variations such as Scheme and Racket, is a unique and under-appreciated programming language. Unfortunately, I never found a customer or employer who wanted to use it. Now, I’m doing development mostly for my own satisfaction, and I’ve largely returned to Lisp (specifically, to the Common Lisp dialect). I’m not going to extol the virtues of Lisp here, there are plenty of places which do that better than I would be able to do. Nor am I a Lisp bigot: there are many languages I’ve enjoyed using (and a few I’ve disliked intensely) and which make good sense in various contexts. I understand why some projects should avoid Lisp, too: it’s easy to learn, but difficult, because of many subtleties, to learn it well, and Lispers are hard to find. However, I’d suggest that more people ought to become acquainted with one or more of its dialects. Of all of the programming languages I’ve used, it’s the one that least often becomes an obstruction, because it can be bent and twisted almost any way you want. Check it out!

Moved, Inactive, and Retired Projects

These projects have been cancelled or abandoned: Cats, sugar, two cans, various CORBA tools, and navajo. If you’re still using any of the code and need some help, please let me know.

Some past work I’m leaving here because it gets a little traffic or because I’m using the code myself are:

ad hoc solutions: Various impromptu, ad hoc programs written to solve specific problems. ⇒ More information...

miscellanea: Items not fitting into any of the above categories. ⇒ More information...

 

 

 

 

Copyright 2018 Michael Marking. All Rights Reserved.
http://www.tatanka.com/software/index.html last modified Thursday, 23-Mar-2017 07:55:48 GMT
Accessed Friday, 14-Dec-2018 01:37:47 GMT from 54.234.228.78:38422
Tatanka, Bionic Buffalo, sysjinn, and sysjinni are trademarks of Michael Marking.