A verbatim headline: “The 5 Ds of Creating Software”

Aleph Infotinuum Services gives this article a non-binding grade of D for failing to include Documentation.

AIS is also sorry to report that not one of those Ds is Dance. Perhaps the intended developer-qua-android audience spends its days dreaming of electric sheep within one or another enterprise’s Dilbert department.

On a more serious note, what’s up with skimping on documentation? Such corner cutting guarantees a diminished user experience. As the article explains, creating software is about more than just hacking code.

After adding Documentation to the hexa-D recipe for software development (which is itself a document), consider prefixing the D with a C for Continuous Delivery. Establish a feasible workflow process (e.g. DevOps, XP, Scrum, etc.) as another wise component of product pre-planning.


Should your employer look toward mob rule for the efficient completion of successful programming projects?

It’s too early to say for certain, but Aleph Infotinuum Services suspects that such an approach solves some of the problems which either stem from or are difficult to ameliorate by way of other programming methodologies (e.g. XP, Scrum, Lean), while letting one or more of the already-resolved process problems back in.

Seriously, though, there is no way to perfect any individual. To extend that logic, there is also no way to perfect any team. Meeting adjourned.

Seriously, though. Problems within any organization boil down to people. Even within your own enterprise, where each employee is guaranteed to be a talented if imperfect contributor with whom others relish collaborating, there are bound to be supply-chain vendors mucking up the works.

Seriously, though. Imperfect people and imperfect processes tend to stew themselves into man hours and business days eaten up in large part by meetings that never seem to adjourn. Where that leads too often is toward market exposure of a struggling company whose problems with supply-chain vendors become exacerbated by consumers who for some reason won’t pay top dollar for all those meeting minutes.

Seriously, though. Your employer can’t get its huge idea with ten thousand features to the store shelves when so much productive capacity is getting lost within meetings. Or, for that matter, ever.

Seriously, though. Why not encourage teams to hold one continuous meeting that spans multiple sprints and even entire careers, during which the topics under discussion get entered immediately into the productivity swim lane where internal product owners and likewise business line managers can observe genuine progress?


Trust your employer’s Minimum Viable Effort for managing its slice of the eternal infotinuum

Getting caught within an undertow of overkill is a recipe for bankruptcy.

After finding herself in a strange home, the storybook character Goldilocks made sure to seek out the perfect meal followed by the perfect nap. Recall what happened to Goldilocks after she frittered away the afternoon until some bears showed up. Eeeek! Talk about perfect being the enemy of good enough …

Setting achievable short-term goals is a laudable best practice, both for software development and for managing the infotinuum. Just as overeager software architectures can become anchors weighing down the engineers responsible for delivering usable products based on such pie-in-the-sky dreams, so too can IA (Information Architecture) eagerness ruin an enterprise’s content lifecycle program before anyone accesses a single single-sourced file.

Indeed, attempts to single-source every piece of content into some ultra-efficient information processing machine can result in a repository filled with modular snippets that for all practical purposes (i.e. aside from boilerplate) are unusable. Other potential pitfalls include escalating necessary plans for accurate metadata into a maelstrom of over-engineered megametadata, or shoehorning an existing business model into the cooooooool new features of the latest ECM solution.

Keep it simple. Keep it viable.


Slimming down your API’s internal JSON and data specifications can help to optimize the consumer experience

Software app developers will appreciate that you are making it easier for them to please their own customers.

When it comes to computer programming, writing is key to producing quality output — code and accompanying documentation alike. If the app developer consuming your API has problems understanding your meaning, you and your employer will have problems maintaining a base of API end users. That in turn represents a recipe for suddenly having an ex-employer.

Keep that readability imperative in mind whenever your enterprise embarks upon a program of internal code optimization. Sure, end users of applications based on your APIs will want assurances that their bandwidth requirements are kept to a minimum, especially if they’re on a mobile device. If, however, an extra few milliseconds will please the end user only at the expense of app developers being frustrated with the cryptic nature of your APIs and their accompanying data specs, a domino effect of dissatisfaction will harm first them and then you.

Don’t even think about optimizing as much as possible only to then pass the incoherence buck downstream (e.g. “The API is sleek and beautiful — they’re just too stupid to code with it well enough”). The fault would, of course, remain within your organization, so recall the notational frustration which the CopperSpice team encountered while trying to make sense of the Doxygen codebase.

Bttm ln: dnt b ovrly vrbse or ovrly sccnct.


A verbatim headline: “Why Most Academics Will Always Be Bad Writers”

The short answer is that they are trained like sea lions to become scholarly half-wits performing dialectical circus tricks for purposes of getting thrown a plundered fish.

Subsidies and Marxism and You Didn’t Build That. Oh my. Institutions of so-called higher education are high on something, over the rainbow in terms of epistemological vital signs. Ph.D has turned out to be an acronym for those who are intellectually PhlatlineD.

As the famous Underground Grammarian, Richard Mitchell described such a doctor-of-flatlined phenomenon within his book Less Than Words Can Say:

There you sit, minding your own business and hurting no man. All at once, quite insensibly, the thing creeps into your brain. It might end up in the storage shelves of the subjunctive or the switchboard of the nonrestrictive clauses, of course, but in your case it heads for the cozy nook where the active and passive voices are balanced and adjusted. There it settles in and nibbles a bit here and a bit there. In our present state of knowledge, still dim, we have to guess that the active voice is tastier than the passive, since the destruction of the latter is very rare but of the former all too common.

So there you are with your active verbs being gnawed away. Little by little and only occasionally at first, you start saying things like: “I am told that . . .” and “This letter is being written because . . .” This habit has subtle effects. For one thing, since passives always require more words than actives, anything you may happen to write is longer than it would have been before the attack of the worm. You begin to suspect that you have a lot to say after all and that it’s probably rather important. The suspicion is all the stronger because what you write has begun to sound — well, sort of “official.” “Hmm,” you say to yourself, “Fate may have cast my lot a bit below my proper station,” or, more likely, “Hmm. My lot may have been cast by Fate a bit below my proper station.”

College students experience what it’s like to have their papers graded by professors who themselves tend to be untalented writers. They do everything they can to impress the bureaucrats, fluffing up their amateur prose with the passive-voice sentence structure that makes them appear more scholarly and official. They spend literal decades sucking up to those who call themselves doctors of pretending to sound more official than they actually are. Indeed, the university system itself represents a pretense of accredited officialdom.


Serving up streams for multi-screen viewer audiences: are QoS (Quality of Service) and QoE (Quality of Experience) things about which only consumers care?

To be fair, QoS and QoE are important to consumers and to producers that wish to remain solvent.

Those who follow the cord-cutting emergence of streaming video have noticed that so-called TV Everywhere is now popular, as is the ABR (Adaptive Bit Rate) encoding which enables different stream configurations for different viewing configurations (e.g. smartphones on the go with spotty WiFi connections as opposed to big screens in the living room with dedicated broadband services).

Consumers themselves remain as finicky as they’ve always been. Be grateful for such good news, because each person spends the vast majority of their life — even when they’re busy at work creating goods or services for others — consuming things that already exist (e.g. desks, steel-toed boots, lunches, etc.). For every incompetent business manager whining that consumers aren’t treating them with appropriate fairness (i.e. fealty) there are several who understand that economic health necessitates treating all issues from the standpoint of the consumer. The great 19th Century French economist Frederic Bastiat added the simple fact that “… the interests of the consumer are the interests of the human race.”

What does that mean to competent managers who wish to help their employer remain profitable without coming across to consumers as whiny or worse? Business survivors learn to ask consumers about their subjective viewership opinions, and also to monitor from end to end, from the camera or server to the viewer’s screen, metrics from QoS and QoE analyses. Consumers care about the quality of their viewing experience, obviously, which implies that they care just as much about the various kinds of QA (Quality Assurance ) and QC (Quality Control) functions that will make or break any producer’s offering. Monitoring your employer’s assets is a way to ensure that all the streaming ducks are lined up in a row, and that they’ll stay in formation during their ether-swim toward their ultimate destination (e.g. a smartphone or a large screen).

Just be sure to watch out for those hunter blinds, by which Aleph Infotinuum Services means third party supply chain vendors (e.g. CDNs) that might be cutting a few corners within their own operations. Monitor their capabilities as well, and be prepared to let them know that it would be easy for your employer to court a competing vendor.


Software-Defined Storage is your (employer’s) friend, for now

Think hybrid solutions, for now, and remain agile, always.

Back in February of this year, Aleph Infotinuum Services posted a blog entry regarding SDN (Software-Defined Networking), an innovative approach to maintaining real-time network efficiency. Every networked service needs access to storage as well, of course, so get ready to meet & greet SDS (Software-Defined Storage).

As a competent manager of your employer’s slice of the eternal infotinuum, you understand that any strategy for content lifecycles necessitates a dedicated program of content management, covering cradle-to-grave operations that range from initial creation and storage through to archiving and eventual destruction. Schedule details will vary depending on the needs of the organization, but such strategies remain consistent across businesses and even industries.

Managing the Big Data associated with massively distributed systems requires shifting into a higher storage strategy gear. For the time being, hybrid storage appears to be playing a stopgap role.

Hybrids represent the androgyny of computing. What such androgyny implies is that hybrid computing solutions represent less an aspect of the natural world and more a product of some specific alchemical mojo. To extend the analogy, malware and outright attack become the tribulations encountered on every path toward a software/hardware magnum opus. Is a bare metal configuration to be considered base or precious? Is this cloud thing going to elevate my self or steal my breath?

Costs for bare metal clusters and farms continue to drop on the CAPEX (Capital Expenditure) side of your employer’s bottom line, as do prices for leasing outsourced operations from third parties (possibly gaining a bonus tax write-off advantage). AIS is betting that the real solution (or ethereal solution) is coalescing toward a rubedo stage … so stay tuned and stay nimble.


Aleph Infotinuum Services posted this entry on

When it comes to documenting API error messages, verbosity is the end user application programmer’s friend

Putting consumers first is the best possible market differentiation.

If you want your employer to stand out from the competition, design and develop and market an API that handles errors with as much coder handholding as those users of the API might need while crafting their applications. Make no mistake, coders will encounter errors while using your API. The $64,000 (or greater) business management question then becomes: how do I as a competent business manager ensure that those errors don’t trap the coders within a confusing hunt for bugs which could be documented to an appropriate level of error message professionalism.

As Aleph Infotinuum Services has mentioned in other MTI posts, a typical Mel doesn’t like documentation responsibilities. That’s because they volunteered for a dialectics-only set of training instructions instead of insisting upon a balanced education featuring equal parts dialectics and grammar — they were naive enough to fall for the lie that so-called STEM is paramount.

Light a figurative fire underneath the Mels. When it comes to public-facing APIs, the documentation is more important to end users than any under-the-hood functionality around which they are trying to build applications. The functionality is a given for consumers, or else they wouldn’t be considering the API in the first place. What end users lack is reasonable insight into how to make the most of their vendor decision.

Wherever consumers are lacking, of course, wise enterprises see opportunity.


Tag your IT

That oh-so-clever (in our heads) play on words reflects just one of the potential strategy holes within enterprise efforts to manage even a miniscule slice of the eternal infotinuum.

Aleph Infotinuum Services assumes that such a play on words is not an AIS original. Still, there is a great gain in productivity waiting for any business that can establish a solid process for creating and managing the taxonomical details of ontological somethings-or-other.

The reason why AIS is willing to risk appearing like an amateur organization in order to emphasize the inherent difficulty with managing the taxonomical details of ontological somethings-or-other is that those two terms have interesting and intersecting histories. Ask a philosopher what they think of the typical Computer Science grad’s definition of ontologies, or vice versa. Such a debate will never end, because settling a debate is dependent upon agreeing to the definitions of the terms and subjects being debated.

In general, data which describe the content of a web site or application or book or periodical or other source of perusable information are known as metadata. Insufficient or improper metadata is a recipe for relegating content to the abstract realm known as dark data (picture a card missing from a library’s card catalogue and the subsequent loneliness of a specific book related to that card).

Dark data can frustrate people both on the inside and on the outside of an enterprise, which in turn might simultaneously increase production costs while harming revenue streams. As a competent manager of your employer’s slice of the infotinuum, consider creating a category of Dark Data with someone responsible for populating it — at least temporarily — with poorly-tagged content.


We have met the cybersecurity enemy and he is predictable

Are you sabotaging your employer’s viability and with it your own professional reputation?

The password for this Managing The Infotinuum blog is 54321. Just kidding. Go ahead, though, and try that password on a thousand random servers, because before long you’re bound to hit the virtual equivalent of pay dirt.

You might have noticed that Aleph Infotinuum Services didn’t recommend a username to go with that lame password. That’s because AIS is trying to avoid a “material assistance to terrorism” frame-up. You might also have noticed that the entire War on Terror is one big one-world frame-up. So … what are the real threats to your organization?

The first place to look is at the reflection you see in any mirror. Although you might try to ensure that your passwords are 20-charater strings of gobbledygook goodness, you (and your work colleagues) are still the biggest problem facing your employer’s IT security program.

Do you stop for coffee at the same place every day? Do you dongle? Are you familiar with the term two-factor authentication and its n-factor descendants? Have you memorized one password that you use to access multiple online accounts — or are you (*cough*) smart (*cough*) enough to have a set of unique passwords that you keep handy on a sticky note attached to your monitor?

There are many best practice cybersecurity examples out there, as well as many antipatterns. Some good advice is to ignore the honey pot giving you that affected come hither look. Some better advice is to avoid mind altering substances like alcohol and weeeeeeeeeeeed. You might even try establishing some countermeasures, like carrying fake passwords in your wallet that provide access only to those servers within your enterprise which IT professionals implemented as a trap.

The bottom line is that there is no bottom to the depths of fraud to which hackers/crackers will go when trying to infiltrate a networked computer system. If there’s any below-the-bottom line, it’s that the worst offenders are often those who pretend to be fighting a War on Terror.