Tag Archives: musings

Management

Formal Management System Core

Leave a comment

Now that I’ve spent a few years working with and thinking about formal management systems like ISO 13485, ISO 27001, and others, I think I would break them down into two general tiers: the Management System Core and Domain Recommendations. In this case, I mean “domain” in the sense of: quality, information security, power systems, vulnerability disclosure, risk, etc.

The Management System Core answers the question: “What is at the heart of management?” It would be comprised of the Top Management, General Documentation, and Feedback/Improvement clauses of the typical ISO document. These are the foundation from which all others could be derived. For the most part, most of the non-core aspects of the standards seem to be little more than best practices, and they’re the parts that change the most between updates.

The Domain Recommendations (requirements) are essentially good practices for the domain — at least at the time of the publication. Quality System Domain Recommendations include things like infrastructure and engineering processes. Security Domain Recommendations include standard security controls.

If your domain doesn’t have an explicit standard, applying the core will eventually get you to a good point. Applying the core — bare — to domains with existing standards may produce a result better than the standard with time. Technologies and techniques get better.

Background

How I Got Here

2 Comments

When talking with people about what I do, it’s obvious that it’s difficult to explain quickly in a way that they understand any of it. I’ve written a bit about that here: Agile vs. Formal Management Systems. What’s even less obvious in a casual conversation is how one could even get to doing what I do, and whether it would be worthwhile. This is the kind of thing that will have to be updated periodically because I’m definitely not standing still. I’ll leave this strictly a description of education and professional development. That’s certainly not the end-all — it’s important to be able to manage what you build and earn, I talk about that here: Phases of Investing. Motivation is also important, but that’s an enormous topic.

In my early years I was a console and computer gamer. I still would be if it didn’t take so much time and produce so little. Gaming was much more a solo activity back then as Internet gaming wasn’t as feasible given available technology. We did figure out how to play Doom multi-player with a modem connection and later we got a couple of computers linked up to play Starcraft and other titles.

I wanted to make computer games. My friends and I would bounce around various ideas for games and talk about making them. We didn’t really have an idea where to start, but I knew programming was involved. I started playing with MS-DOS batch file scripting and made a few small useful things.

In high school I was lucky enough to have programming classes available to me. I jumped on them. There we learned the (even then) relatively obsolete QBASIC and got an introduction to C++. I think high school programming classes are common-place now, and I would encourage anyone to take advantage of them.

At age 16, I started to work at a local retailer. This isn’t the first job that I had, but it is the first one that I took seriously. I would have been happy as a cashier or pushing carts, but they wanted me at the service desk. I didn’t like it, but I did it. In retrospect, it really helped me to figure out how to interact with people better — especially people who were starting off upset. I probably owe a lot more to that experience than I typically give it credit.

I went to university and studied Computer Science and Mathematics. I wasn’t sure what I was getting into when I started, but it turned out that I liked the Computer Science side a lot.

Throughout my school years I continued poking at programming projects — mostly with the goal of making games. I picked up PHP and MySQL to make a small, ultimately unused, web site. At the time, there were several massively multiplayer HTML games that I thought I could take a swing at.

This small web site was key in helping me land my first programming job during my sophomore year. It demonstrated some ability that a resume would never communicate alone. I ended up helping a small company build and manage their web applications. Looking back, it was pretty poor work, but it did help them. That job beat into me the value of testing, revision control, and clean code in ways that the classroom had not yet been able to emphasize. There were very lax controls around the deployment of code, and I hadn’t developed nearly the required level of discipline for checking my work. It bit us badly. The complete embarrassment of bringing the productivity of an entire office to zero is something that most kids don’t get anymore. It changed me. Before long I had a script for verification that was better than anything they ever had. Other hiccups encouraged me to bring revision control (CVS) to the office.

Realizing the valuable skills I’d learned in just a few short months on a programming job, my view of classwork dimmed. I got through my classes with little enthusiasm, but they were definitely good for me.

I took a generalist approach in school. I tried a little of everything. Before I left undergrad I had seen the basics of operating systems, compilers, security, databases, networking, graphics, software engineering, algorithm analysis, and digital logic. The advice seemed to be to specialize, but that didn’t appeal much to me. Why specialize if you don’t know why you’re specializing? I think I’ve since used aspects from most of those classes. It was worth it.

In between classes I figured out how to use Linux. I started with Slack 8 (not recommended), then tried Mandrake, and eventually settled on Debian. With that I set up a small home network made up of old computers that I had collected over the years. That taught me a lot about networking and some sysadmin basics. Today it’s easier to get started with Linux. The graphical user interface (GUI) on those older versions wasn’t as developed as it is today, so I stuck with Windows for my day-to-day. Today I’m almost exclusively using Ubuntu.

My first job out of school was programming small embedded Intel 8088 and ARM7 processors. They were plugged into custom boards designed by the company. My first project was to work with the hardware engineers to design a new board using a relatively “new” interface called USB. Embedded development was new to me, but the new processor and board had so much more CPU capability and memory available, that it rarely gave me a problem. Virtually every significant piece of code I wrote for the board had an accompanying program to test it. I was almost doing unit tests without knowing it. We also created a standard hardware testing harness and accompanying software to verify that all the parts of the board were communicating as expected.

In the 3 years I worked at this job, I grew from a competitive, passive-aggressive, pain-in-the-ass know-it-all to a much more mellow, more humble pain-in-the-ass. Partially that was due to doing meaningful work over a longer period of time. That’s a difficult experience to find in school. I also credit the fact that I was working with a wide diversity of experience. Most of my co-workers were at least a decade older than me, and several had started working at that company before I was born. They had a long view of their work that had rarely occurred to me, but I slowly adopted it. That’s also a difficult experience to find in school. There was also a wide variety of professional backgrounds: mechanical engineers, electrical engineers, embedded engineers, UI engineers, chemists, biologists, and veterinary experts. The spread of domain expertise was so varied that I regularly had to rely on other people to get my job done. Some level of humility was a requirement. That’s also a difficult experience to find in school.

In 2007, another opportunity came along, and I jumped at it. This time I would be working on some compiler-like tools. Specifically, we were taking programs apart and reassembling them with some modifications. Testing was crucial to this company, and they had the best product validation practices I had seen to-date.

During this time, I found a renewed appreciation for classwork. I could see that my classroom training in the more abstract topics like algorithm analysis was an asset that some others were lacking. It also hit me that the abstract concepts taught in school will never announce themselves as necessary. They just appear as a lot of work that the knowledgeable know how to do faster and better. It reminds me of the people who claim they’ve never needed some kind of math. Strictly speaking, you don’t need math, but you’re probably doing a lot of extra work without it. Throughout these years I took advantage of computer science and math classes at the nearby university. I have not regretted it.

The next group I worked with made a distributed system that coordinated data across hundreds to tens-of-thousands of sites. Their development practices needed some help, and I was more than happy to provide it. Their historical decisions throughout the product’s history had made it a very support-heavy organization. The support team was well-staffed and very busy. Tier-three support was a phone that the engineers traded amongst themselves for some extra pay, and it was a nearly guaranteed angry, late night phone call.

We wanted to get ahead of the support calls. I and a couple of other engineers led an effort of infrastructure and testing improvements. Product deliveries went from hand-assembled to automatically generated. The database went from a mish-mash of direct table edits to a set of scripts that were guaranteed idempotent through arbitrary upgrade paths. Unit testing was added at every level. Interface testing was introduced every time one was touched. The UI also got a lot of testing attention.

The customers went from regular failure on installation (not to mention downstream problems) to zero installation failures in about the space of a year. It was remarkable. At one point I noticed someone with the tier-three support phone, which I had been avoiding. I asked him how it was. His answer: “It never rings, so it’s free money.” That was a moment of silent celebration. We had spent a lot of time to make things better for the customers, but I hadn’t realized that we had almost completely transformed the despised support phone into a paperweight.

Once the raging fires were squelched down to contained bursts, I put some effort into learning how to do large-scale communication correctly and started collaborating with local grad students on what the right design would look like.

Unfortunately, circumstances worked out such that the parent company saw our office as unnecessary and closed it — perhaps we engineered around the urgent workloads a little too well.

I ended up working on more build tools afterward. I would alternate between being a feature developer and team lead. Then the company signed a deal requiring compliance to a formal quality management system, and my name came up as someone to assist with the deployment. At the time I thought it would be a good way to drive the company and products toward better practices through measurement and analysis, so I jumped at it. The job ended up being a lot of paperwork and document management, but the spark of a data-driven effort remained, and I drove on. One of the greatest benefits of this position was that it gave me the clearest picture of company organization and management that I’ve ever had, and I find it’s very relatable to the concepts learned in computer science.

In retrospect, my career path seems meandering. I went after the work and positions that seemed right at the time, but there was no single theme to the motions except “Make Things Better.” Perhaps a more deliberate drive would have turned out better in some ways, but I really have no complaints.

Side Projects

In between jobs, I’ve never been not working on a side project — most of them never published. Sometimes I would find an open source project that was making my life easier in some way and start making the changes that I wanted. Other times I just worked on things I was interested in at the time. Sometimes it supported my job, sometimes not. Professional work is often about negotiating the trade-off between doing things well and doing them fast — with a lot of business pressure on fast. On the side I would often explore ways to do things well, and it usually worked out that the lessons learned could be applied to the job.

Working from Home

If you’re able to get work done without anyone looking over your shoulder, you’ll have no problem finding a company willing to let you work wherever you want. I’ve heard that remote work actually makes people more effective in some cases, but I’m not so sure. The corporate world seems to go back and forth on this. As nice an idea as it sounds, there are some complications.

The biggest one: isolation. I didn’t realize how much I got out of the daily office chatter until it was absent. There is no happy hour with the co-workers, and office events are much harder if not impossible to fit into the schedule. You’ll frequently find that you’re not aware of things that are happening in the company. Some regularly scheduled chat times might go a long way.

To make things worse, if you work and are a family man, you may find that 80 hours of your week are spoken for, so there’s little time to develop any kind of professional relationships in your area. I would recommend you find some relevant groups to interact with and make a point of doing it. I’ve found that there are valuable business relationships to be found among the regulars at coffee shops and breakfast joints.

Another problem: infrastructure. Residential power and communications aren’t as reliable as commercial, I’ve found. I’m usually dealing with 2 multi-hour power outages per year. It’s manageable, but annoying. Communications outages are similar. The answer is: redundancy, but it’s extra headache that you typically wouldn’t have to deal with in an office.

Things I Might Do Differently If Starting Over

I realize that things have changed a bit since I went through school, and I think there might now be better ways to do it. For someone starting today, I would recommend Python as a starting language. It’s relatively simple and there’s a lot of online help for getting started.

I might also suggest a hard look at the online learning resources. There is an advantage to having a group of peers trying to learn the same thing you are: it brings out the useful questions. However, college tuition is getting expensive, the colleges are usually not where you are, and communications technologies are
constantly improving. If you can find a small group of locals interested in the same online course and maybe someone more knowledgeable to guide the group, you’re set.

If I were starting again today, I would put more focus into freelance work sooner. Freelance gives you the freedom to look for interesting work in a way much less restrained than an employer would typically allow. Full-time employment provides income security (but be cautious). Full-time employment is great when you don’t know what you’re doing, but after a while it can feel constraining. If you can get someone to pay you to do exactly what you want to do, there’s nothing better.

I would publish more hobbies. You may not think they’re valuable or clean enough to present to the world, but others may disagree. If no one can ever see it, you’ll never know what something is worth to the world. I’m improving this as I write.

Thoughts

Big vs. Small

1 Comment

In my decade plus of experience in the working world, I’ve managed to work for large and small companies. I’ve noticed how different
organizations seem to operate.

Some groups are small, lean, and mean. They don’t have much to work with, and everything they do is extremely focused on their
product(s). These companies are intense and, I think, fun to work for, but they can’t survive many hits. As a result, if they manage to hang on, they probably have a very capable team that can work wonders.

Then there are the larger organizations that don’t seem quite so
focused on what they deliver. Once you’ve spent a few hours in
meetings trying to optimize your software build processes to take full advantage of the various international tax benefits, you may realize that a lot of work performed by people all over is done to get around obstacles that we set up for each other. You also quickly realize that there is nothing more tedious, and less worthwhile on the whole — especially to technically-minded people.

I have never seen that at a small company. Small companies don’t have the resources to worry about that kind of thing or the scale to make it pay off. They focus on the product or service that they’re delivering and not much else.

However, all of the larger organizations that I’ve worked for have been much more profitable, and I wonder why that is. There’s a simple explanation — the bigger companies do more valuable work. Extremely valuable work would allow a company to grow faster than others and support the larger overhead of organizing so many more people, processes, etc. Given what I’ve seen at large companies, I’m not so sure this is the only, or best, answer.

The value of work or a product is dictated by reality. How much time does the product save? What are the side-effects of using said product? What are the risks? The net consequences of all concerns indicate the intrinsic value (regardless if that’s reflected in market value).

We set up rules to guide us toward maximum value. Distinguishing good rules from bad rules isn’t always easy. Bad rules can masquerade as good rules for a time, and good rules can go unnoticed. As a result, this discovery is a meandering process, but ideally the rules guide us toward maximum value.

Effective rules might include the US Constitution. They’ve produced a fairly stable country that has managed to be very productive. English Common Law might be another example. It’s a pattern of behavior that has positively influenced every place that it has touched.

For reasons stated above, the rules regularly fall short of optimal. When they do, they force the people and organizations that are required to follow them to trade off real value creation for compliance to the rules to minimize penalties. As the gulf between the enforced rules and the optimal rules widens, those people and organizations are forced into a particularly difficult spot.

On one side, reality can’t be ignored indefinitely. People need to breath, drink, eat, sleep, etc. If those needs can’t be met, people will get sick and die — at an arbitrarily large scale. Accumulated wealth can act as a buffer against bad decision making, but it won’t last forever.

On the other side, the man-made rules can be ignored to the extent that the enforcing organizations can be avoided or manipulated. Many times man-made rules are also created in such a way that they don’t apply to the smallest of organizations.

When caught between these two sides, the combination of acting against reality, not complying with bad rules, or both, will start killing companies. The ones that seem to survive are either so small that the rules don’t apply or they can avoid detection by enforcement bodies; so large that they can take advantage of relatively expensive techniques to comply with or avoid the rules; or so large they can directly influence the rules or their enforcement.

Given this, in an environment where the rules are good, one might expect to see companies of all sizes flourishing or at least surviving to some extent. In an environment where the rules aren’t as good, I would expect to see some fraction of middle-sized companies disappear. The smallest companies can escape the rule or detection, the largest companies can financially or politically maneuver, the middle guys take the hit.

How do the large companies have an advantage? New fixed costs are a relatively smaller proportion of their revenues and (presumably) profits. This includes complying with regulations, legal battles, lobbying, and moving offices or plants. New taxes are maybe generally less of a burden to the large companies, but the accounting research needed to minimize tax burden via international accounting also acts as an alternative fixed cost, yielding the above advantages.

These all might be described as political economies of scale. The advantage isn’t in discovery or creation, but in being able to maneuver the political landscape. I believe this is almost exclusively the domain of the large organizations.

Computing

Language Musing

Leave a comment

If you’ve been in the software development world, you may have noticed some larger themes while going about your day-to-day. As you create, you (or I) tend to start with relatively large, unruly blobs of code. Then in several passes, those large, unruly blobs of code are broken down into smaller, more structured, and more generalized bits that are used by more specialized bits. This is the essence of functional decomposition, but it can happen along interesting axes. Most languages allow you to break down main routines into subroutines, but can you break down types? Some languages let you break down types, but can you parameterize them? Some languages let you parameterize your types, but can you classify and manipulate your language elements based on their properties?

We can watch computer language development go from simple to abstract, and this mirrors the path of mathematics. The power of the abstractions cannot be understated. As each new abstraction layer appears, our ability to compactly express ideas grows by some exponent. The cumulative effect will have a total power difficult to predict.

Mathematics is a language of “what is true.” One of its peculiarities is that it can be completely removed from the physical world and still work. Mathematics of some form acts as the core of most software languages, but that’s not their totality. We can call the myriad ways to express truth as Truth Language.

Programming languages take some way of describing “what is true” (i.e. mathematics and logic) and layer on top the ability to talk with a computer’s inputs and outputs. This makes software languages capable of interacting with the world.

Thus, programming languages are languages of sense and action. Every piece of software in its most generalized form is Input -> Computation -> Output [ -> Repeat ]. The inputs are some form of sensory data — key presses, camera data, mouse movement, network packets, etc. — that inform the rest of the process. The Computation is a series of transformations based on known truths, and the Outputs manifest the results of this computation in the world. These processes can range from simply putting characters on a screen to the full complexity of running a manufacturing plant and beyond. Whatever the goal, it’s manifested in the real world. We can call these Action Languages.

Not only do we use programming languages to direct computers, but we use them to communicate with each other about what computers will do or have done. The emphasis on human readable code is strong in the software engineering discipline(s). One might also notice that the core of general human language is Action Language — we use our language largely to describe things to do.

However, general language includes more layers atop Action Language: a semantics of history and future, past actions and intent. Computer systems generally express past as log of some form while intent is expressed as an event handler configuration or schedule. These things tend to be described within software languages by how they are configured and/or formatted rather than as first-class elements of the software languages themselves, but there may be a slow shift toward more formality.

By advancing the state of Action Language, computer science is essentially advancing the state of general language. Though we don’t yet completely use software languages this way, it’s clear that we’re educating millions at a time in their use to communicate both with our machines and each other. The long-term effect of this can only be more power and precision in our ability to express ideas and intent.

More than communicating amongst ourselves, software language is rapidly allowing us to express intent to and command the universe itself. Computers were an impressive step, giving each individual a capacity for logical and mathematical expression never before possible by even the whole of humanity. As technology advances toward increasingly more advanced creation machines like CNC machines and 3D printers, our words, expressed as software, achieve increasing creative potency.

To date, software represents the pinnacle of the power of the written word, and we still seem to have a lot of improvement ahead of us. If you don’t yet know how, pick up a programming book or tutorial and get started. Incomputency in the 21st century will be looked on as illiteracy in the 20th.

Thoughts

Ultra-Resolution Conclusion

Leave a comment

We’ve reached a point with device displays where the retina is physically incapable of distinguishing between pixels, but display manufacturers keep pushing higher resolutions. “To what end?” we might ask. Well, I have a few thoughts.

True 3D Displays

I’m not talking about the stereo-image garbage that has been pushed at us for the last decide by movie theaters and display vendors. I’m thinking light-field emitter. Each “pixel” on the screen might be composed of 10, 20, 100 directional pixels, each producing a different color and intensity. You could see 3D without any glasses. The headache-inducing problems with stereo-screens might be eliminated. You could view a Lytro image in its raw form. User interfaces and content could be much more immersive.

Power Saving, Secure Displays

Building on the last thought, our displays currently feed us information by blasting light out in a hemisphere — we’ve gotta have those viewing angles. Well, coupled with a face-tracking feature, the ultra-high resolution display could emit light only in the direction of the user, saving power from the light that would have otherwise hit inanimate objects or prying eyes.

Simultaneous Multi-use Display

Never again suffer through watching a movie or show that you don’t like. Two people, watching from different vantage points, could watch two different things. In fact, you could display as many different 2D media as you have emitting angles. Watch two movies. Play two, four, or maybe eight-player console games where each player has their own view.

There are probably many more possibilities. The future looks awesome.