Category Archives: Thoughts

Management Systems and Software Engineering Similarities

I spend my time between software development and management system development, and the similarities have never been clearer.

Business is about getting things done in a sustainable way. Improvement is almost always the name of the game. Computer science is all about solving problems with the fewest resources. Software engineering is the process by which software eventually achieves that goal. These things could not fit together much better.

Even the terminology matches. Operating systems procedures and processes match their management system counterparts definition. This was almost certainly adopted by the original operating systems developers as it was certainly their goal to apply software to business problems. The major distinction is that one executes via teams of people whereas the other on machines.

Formal Management Systems focus on establishing documented activities, defining how to change them, and determining how to evaluate them.

There are so many analogues to software engineering. The documentation system is the source control system (like git). The training system is the compilation and deployment processes (note: “training” computer systems is much more predictable). Complaint handling and CAPA are your bug tracking system, software internal audit is basically the regression test suites. The Top Management functions, choosing software process direction and evaluating the effectiveness, are handled by the Product Owner.

Formal Management System procedures could be treated as software, with some level of unit and regression testing. All of the lessons from the move to micro-services could be very quickly applied to management system processes including: error management, fault tolerance, and monitoring.

All of this is not to overlook the extra complexities of management systems where people are the primary executors. I just happen to be less familiar with those.

Thoughts on ReactJS

I’ve spent some time with ReactJS recently (and in the past), and I thought I would make some notes.

ReactJS is a UI management framework created for managing the presentation and interaction of UI components on a web app (or native mobile applications with ReactNative). It manages the structural document changes behind the scenes and renders them to the browser/screen.

There is a paradigm called Model-View-Controller (MVC) for UI development. The Model represents the data layer, the View represents its display, and the Controller represents the code used to mediate the two. I’ve said in the past that if the Model were rich enough, the Controller would be unnecessary.

ReactJS fills at least the View side of the MVC paradigm — possibly even the View-Controller. There are some standard data-management libraries that frequently accompany it, but they are optional, and I have not used them.

For each ReactJS UI component, you follow the lifecycle through the construction, presentation, maintenance, and teardown of the bits that get rendered to an HTML document.

Despite my love for the functional model, UI design is fundamentally an exercise in state management. There is no user interaction with anything that isn’t changing small stateful pieces one at a time to achieve some effect. However, I would say React does a good job of delineating where state change should happen vs. the side-effect-free computations.

The maintenance phase of each component is very unstructured. State updates happen either through internal updates (this.state) or through the owning component (this.props), and it’s up to the developer to wire the downstream effects together via JS code. The one exception to this is the update of the presentation, which always happens if the component state changes (except in rare circumstances).

In the past, I built small UIs of communicating state machines. React would have been a great tool to have to help with the management of adding and removing components, but that’s about where the benefit would end. I was ultimately going for much more granular control of the UI component interactions. I would rather spell out explicit data flows and state changes in a model than have them implicitly buried in blocks of code.

I think React has the potential to be the foundation of a much richer UI management framework. There are frameworks like AngularJS and VueJS that I’m much less familiar with that may already do what I’m looking for. I’ll have to check them out at some point. My preference for the “minimal” option took me down the ReactJS path, and I like it.

Big vs. Small

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.

Ultra-Resolution Conclusion

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.