Today's edition of the Toronto Star carried an item that made me smile in three different senses: Scientists Hack DNA to Spread Malaria-Resistant Gene. On a purely topical level, this could be A Really Big Deal. That makes me smile.
On a purely geeky level, the use of the term "hack" was encouraging. I/T folks like myself have been trying for years to make the distinction between "hackers" (the DIY tinkerer types who have no time for Apple-level polish) and "crackers" (the folks who keep the credit monitoring firms in business...and regular I/T folks awake at night). Alas, the rest of the world doesn't make that distinction, so even white-hat "hackers" are tarred with the same proverbial brush.
And yet...no one (geek or non-geek) likes mosquitoes, so who wouldn't get behind "hacking" their DNA, amirite? [grin]
But the question of semantics and PR is the least of the problems here. Because I yet again have to smile--albeit wryly--at the huge obstacle common to hackers across all disciplines. Namely, the gulf between a working prototype in the lab (or hackathon-occupied conference room) and full-scale adoption in the real world.
Don't get me wrong--this is really-most-sincerely NOT schadenfreude. Half a million lives a year are at stake--most of them children. And the health of two hundred million more people each year is in balance. One would be very, very hard-pressed to overestimate the significance of eliminating mosquitoes as a vector for malaria.
There are 3,500 modern species of mosquitoes, and
their lineage dates back 226 million years. Before deliberate "gene
drive intervention," humans were already triggering the development of
new species by dint of pesticides. "Hacking" every skeeter on the planet will be a knock-down, drag-out slog of decades. But it's a worthy fight...and it sure beats the tar out of poisoning the ecosystem with whatever hell's broth Dow is cooking these days.
As a programmer/tinkerer, my goals aren't even a tenth so audacious and world-changing. But that doesn't mean that I can't appreciate the scaling issues. And the wherewithal it will take to surmount them. All the best, my fellow hackers...you're going to need it. And then some.
Monday, November 23, 2015
Thursday, November 19, 2015
Permission vs. Excuse
We all know that one person. Likely we know multiple flavours of
that one person, but let's just generalise for simplicity here.
That one person of whom I speak has the Great Idea. Or above-average talent. There's no reason why they shouldn't do/make The Thing (whatever it is) that would make the world better. Except that they're being stalked by failure. And so your offers to link them with people people who could help them are sabotaged, if not rebuffed outright. Your encouragement disappears into a black hole. The time, you see, is never quite right. There are too many people willing and able to take advantage of them.
We might, even to a fractional degree, be that one person at some point in our lives. You know, making up excuses before we even do or make The Thing.
The bad news is that we will fail. The good news is that we will fail more than once.
Which sounds illogical until you consider how empowering that is. Give yourself permission to fail, and you will be more than equipped for the next failure. And the next. And so on.
Giving yourself permission to fail is not the same as making excuses ahead of time. The saying goes that it's better to seek forgiveness than to ask permission. This is one of the glaring exceptions to that rule. Even so, seeking forgiveness for failure is likewise not at all the same as making excuses.
Excuses are pernicious things, and can rob us twice. They allow us to declare bankruptcy on our responsibility for The Thing not working out the first time. But they can also give us a pass on learning from failure. Which makes it less likely that we will try another way to make/do The Thing...or The New Thing.
But with the permission to fail, it's incumbent on us to clearly define "failure" from the outset. How will we know what failure looks like? What's the plan for changing course to avoid a crash? What can we salvage in the event we crash anyway? Sure, those questions take some CPU cycles. Then again, so does sweating the timing of The Thing, or paranoia that someone will steal The Thing from you.
Now, if my Gentle Reader will excuse me, I have to go practice what I preach and fire off an email or two so that I can get back to The Thing in earnest.
That one person of whom I speak has the Great Idea. Or above-average talent. There's no reason why they shouldn't do/make The Thing (whatever it is) that would make the world better. Except that they're being stalked by failure. And so your offers to link them with people people who could help them are sabotaged, if not rebuffed outright. Your encouragement disappears into a black hole. The time, you see, is never quite right. There are too many people willing and able to take advantage of them.
We might, even to a fractional degree, be that one person at some point in our lives. You know, making up excuses before we even do or make The Thing.
The bad news is that we will fail. The good news is that we will fail more than once.
Which sounds illogical until you consider how empowering that is. Give yourself permission to fail, and you will be more than equipped for the next failure. And the next. And so on.
Giving yourself permission to fail is not the same as making excuses ahead of time. The saying goes that it's better to seek forgiveness than to ask permission. This is one of the glaring exceptions to that rule. Even so, seeking forgiveness for failure is likewise not at all the same as making excuses.
Excuses are pernicious things, and can rob us twice. They allow us to declare bankruptcy on our responsibility for The Thing not working out the first time. But they can also give us a pass on learning from failure. Which makes it less likely that we will try another way to make/do The Thing...or The New Thing.
But with the permission to fail, it's incumbent on us to clearly define "failure" from the outset. How will we know what failure looks like? What's the plan for changing course to avoid a crash? What can we salvage in the event we crash anyway? Sure, those questions take some CPU cycles. Then again, so does sweating the timing of The Thing, or paranoia that someone will steal The Thing from you.
Now, if my Gentle Reader will excuse me, I have to go practice what I preach and fire off an email or two so that I can get back to The Thing in earnest.
Wednesday, November 18, 2015
Crisis Management vs. Management by Crisis: A Cautionary Tale
In the year 1310 CE, The Most Serene Republic of Venice had hit one of the rockiest points in her 1,100-year career. Simply put, she was at war on too many fronts.
La Serenissima was entirely dependent on trade -- not only for her prosperity, but survival itself. Comprised of a collection of small islands (notoriously vulnerable to tides and earthquakes), she could no longer grow her own food, much less the timber for the ships that weighed anchor throughout the Mediterranean, Levant, Black Sea, and occasionally the Atlantic. (The "John Cabot" who crashed Canada's party in 1497 in the name of England was in fact "Giovanni Cavuto," a citizen of Venice.)
But Venice's Middle Eastern trading post, Acre, had disappeared when that Crusader-held city fell back into Muslim hands. She was by now paying the price for the greed and ruthlessness of her for-profit (cough!) "Crusade" (cough!) a century before: She was on the outs with the Byzantine Emperor, and many of her principal Constantinople residents languished in prison. Again.
Closer to home, her on-again-off-again war with hated rival-city Genoa had resumed, and, for the moment, Genoa was in the lead. And territorial squabbling over the city of Ferrara had brought down the wrath of Pope Clement V. The latter, in addition to spiritual penalties such as forbidding baptisms, weddings, and funerals, also included an injunction to the rest of Christian Europe against trading with Venice.
One might expect that in times when a storm appears on the horizon, people would put aside their differences and face the common dangers united. After all, the Venetians had certainly been more than capable of this before (and would be again). In this case, however, one would be very wrong.
The fight with the Pope, for instance, had been the most avoidable part. The "old guard" nobles of Venice favoured conciliation, while the nouveau riche patricians tended to be war hawks. Debate had been fierce, and had even spilled into street-bloodletting. But, in the end, the hawks had carried the day...with disastrous results.
Now, Venice's political system was All About checks and balances. Relatively early-on, she had rejected the notion of hereditary monarchy. At the top of her social and political order was a Doge -- a title that means "Duke." In reality, the office was rather analogous to that of the U.S. President, except that it was for life (or retirement) and its powers decreased, rather than increased, over the centuries. Once, "election" had nominally been a matter of popular accord; in later centuries its Rube Goldberg complexity made the U.S. horse-race of debates, primaries, and the Electoral College look straightforward by comparison.
In the late 13th and early 14th century, however, this office's authority was still very real. The current Doge, Pietro Gradinego, being from the newer clans, had been the loudest of the war hawks. And, in the threadbare tradition of arrivistes everywhere, his other (ahem!) "gift" to Venetian history was the consolidation of his class's gains by shutting out everyone below them on the social ladder. Thus, only members of certain families were henceforth allowed to serve in what functioned as Venice's legislature, the Maggiore Consiglio. Already tending to oligarchy, its exclusivity was given the force of law in 1299.
Despite suppression by the police, the unrest, demonstrations, and public blood-letting continued. As Doge Gradinego's popularity plummeted, his arrogance increased. The "old guard" (which included the Querini and Tiepolo families) plotted government overthrow. For reasons unknown to history, they chose the dodgy, if dashing, Bajamonte Tiepolo as their leader.
As revolts go, this one was more than the usual let-down. Tiepolo, for one, had absolutely no desire to roll back the oligarchy: As far as can be determined, he planned to set himself and his allies up as the rulers of Venice, sweeping away centuries of constitutional safeguards.
But one of their co-conspirators lost the nerve (or stomach--it doesn't matter which) for the enterprise and had already informed on them. A wild summer storm prevented one of their three contingents from linking up with the rest. Another contingent ran into an ambush, and those who escaped had their attempts to regroup frustrated by the painters' guild (whose loyalties were certainly to the Republic, if not its Doge). More ignominiously, Bajamonte Tiepolo paused his assault at an unlucky spot by the house of a old woman who attempted to kill him by dropping a stone out her window. She killed his standard-bearer instead, but the confusion (plus the raging storm) took what wind remained out of Tiepolo's sails.
Surprisingly, the Bajamonte Tiepolo party (standard-bearer excepted) came out relatively unscathed, but only because they had the great, good sense to retreat to a section of the city more hospitable to their cause. He was sentenced to four years' exile and his house pulled down, along with that of his Querini co-conspirators*.
But freak storms and feisty old ladies aside, the Venetian government had been lucky...and they knew it. The next (and heavily secured) session of the Maggior Consiglio addressed the not-new problem of efficiently responding to sudden crises. The issue was made more poignant by the fact that the Consiglio's exclusivity--which would only increase over the years, as the sons of noble fathers born to "commoner" mothers would be barred--set off a scramble to prove eligibility...and thus swelled its ranks.
Their solution was to streamline the handling of time-sensitive business (such as rooting out conspirators) by appointing the tribunal known as the Council of Ten. (A misnomer, by the bye: The Doge plus six more elected officials brought the effective head-count up to seventeen.) True to the Venetian phobia of autocracy, checks and balances were baked in from the get-go: Terms were limited. Multiple members of the same family could not sit on the Council at the same time. To prevent a single person from wielding too much power, it had three "captains," rather than one, and their terms were fixed at a single month. Additionally, "captains" could not go out in public where they could be bribed or listen to accusations that were not vetted by the entire Council. And as the ultimate safeguard, the lifespan of the Council was set at two months.
As my Gentle Reader will doubtlessly be unsurprised to learn, that last fail-safe didn't quite work out as planned. A clause allowing for two-month extensions to its mandate was invoked again...and again...and again...and the fiction of "extension" recurred for another two dozen years until the Council's permanency was made law in 1334. Its term expired only with the Republic itself in 1797.
Do the math: An "emergency" two-month response to a specific crisis lasted very nearly half a millennium. During those five centuries, the Ten took on increasing power as, among other things, Venice's spy agency, secret police, Dept. of Defence, and diplomatic corps. Also unsurprisingly, its secrecy and utter non-accountability earned it a sinister reputation, within Venice and western Europe at large.
In fairness, the Ten's efficiency to a large degree justified their extraordinary powers. Checks and balances were kept, and even increased. Alas, these became increasingly meaningless. Two and a half centuries after permanently legalising the Council, even the Maggiore Consiglio was scarcely capable of exempting review of its own laws by the Council...and little else. As La Serenissima glided into the dolce far niente era roughly (and ignominiously) ended by Napoleon, the Ten's corruption was merely one tumour in the larger cancer eating the Republic.
Yet as much as historians so often succumb to an over-dramatic tendency to hang their story around those at the very apex of society, in this case I consider that dangerous. History is not biography, unless it's in a very collective sense. And that's what makes the events of seven hundred years ago and (for me, anyway) a continent away such a very modern tale.
Technology, true, is occasionally a bona-fide game-changer (although, it turns out, this happens less frequently than you'd think...and certainly doesn't live up to predictions). But the human condition has been fairly immutable over the centuries. Our biggest mistake in the West has been to think of our hothouse as the world and then freak out when an outside stone smashes a window. And our second-biggest mistake is to deny that the stone bears our fingerprints (e.g. al-Quaeda, Daesh, the Taliban).
Ignorance of 13th/14th century Venetian history is perfectly understandable (unless, of course, you're a nerd that way). But ignorance of recent history is inexcusable. Most especially when we allow our soi-dissant "leaders" to let past missteps point the way further down the wrong path.
- - - - -
* A somewhat ridiculous coda occurred when the Querini house was found to be co-owned by three brothers, one of which had had absolutely nothing to do with his guilty siblings. Because destroying only two-thirds of the house proved problematic, the Venetian government sensibly (and fairly) bought out his share and then razed the structure. History can be goofy like that.
- - - - -
Bibliography:
La Serenissima was entirely dependent on trade -- not only for her prosperity, but survival itself. Comprised of a collection of small islands (notoriously vulnerable to tides and earthquakes), she could no longer grow her own food, much less the timber for the ships that weighed anchor throughout the Mediterranean, Levant, Black Sea, and occasionally the Atlantic. (The "John Cabot" who crashed Canada's party in 1497 in the name of England was in fact "Giovanni Cavuto," a citizen of Venice.)
But Venice's Middle Eastern trading post, Acre, had disappeared when that Crusader-held city fell back into Muslim hands. She was by now paying the price for the greed and ruthlessness of her for-profit (cough!) "Crusade" (cough!) a century before: She was on the outs with the Byzantine Emperor, and many of her principal Constantinople residents languished in prison. Again.
Closer to home, her on-again-off-again war with hated rival-city Genoa had resumed, and, for the moment, Genoa was in the lead. And territorial squabbling over the city of Ferrara had brought down the wrath of Pope Clement V. The latter, in addition to spiritual penalties such as forbidding baptisms, weddings, and funerals, also included an injunction to the rest of Christian Europe against trading with Venice.
One might expect that in times when a storm appears on the horizon, people would put aside their differences and face the common dangers united. After all, the Venetians had certainly been more than capable of this before (and would be again). In this case, however, one would be very wrong.
The fight with the Pope, for instance, had been the most avoidable part. The "old guard" nobles of Venice favoured conciliation, while the nouveau riche patricians tended to be war hawks. Debate had been fierce, and had even spilled into street-bloodletting. But, in the end, the hawks had carried the day...with disastrous results.
Now, Venice's political system was All About checks and balances. Relatively early-on, she had rejected the notion of hereditary monarchy. At the top of her social and political order was a Doge -- a title that means "Duke." In reality, the office was rather analogous to that of the U.S. President, except that it was for life (or retirement) and its powers decreased, rather than increased, over the centuries. Once, "election" had nominally been a matter of popular accord; in later centuries its Rube Goldberg complexity made the U.S. horse-race of debates, primaries, and the Electoral College look straightforward by comparison.
In the late 13th and early 14th century, however, this office's authority was still very real. The current Doge, Pietro Gradinego, being from the newer clans, had been the loudest of the war hawks. And, in the threadbare tradition of arrivistes everywhere, his other (ahem!) "gift" to Venetian history was the consolidation of his class's gains by shutting out everyone below them on the social ladder. Thus, only members of certain families were henceforth allowed to serve in what functioned as Venice's legislature, the Maggiore Consiglio. Already tending to oligarchy, its exclusivity was given the force of law in 1299.
Despite suppression by the police, the unrest, demonstrations, and public blood-letting continued. As Doge Gradinego's popularity plummeted, his arrogance increased. The "old guard" (which included the Querini and Tiepolo families) plotted government overthrow. For reasons unknown to history, they chose the dodgy, if dashing, Bajamonte Tiepolo as their leader.
As revolts go, this one was more than the usual let-down. Tiepolo, for one, had absolutely no desire to roll back the oligarchy: As far as can be determined, he planned to set himself and his allies up as the rulers of Venice, sweeping away centuries of constitutional safeguards.
But one of their co-conspirators lost the nerve (or stomach--it doesn't matter which) for the enterprise and had already informed on them. A wild summer storm prevented one of their three contingents from linking up with the rest. Another contingent ran into an ambush, and those who escaped had their attempts to regroup frustrated by the painters' guild (whose loyalties were certainly to the Republic, if not its Doge). More ignominiously, Bajamonte Tiepolo paused his assault at an unlucky spot by the house of a old woman who attempted to kill him by dropping a stone out her window. She killed his standard-bearer instead, but the confusion (plus the raging storm) took what wind remained out of Tiepolo's sails.
Surprisingly, the Bajamonte Tiepolo party (standard-bearer excepted) came out relatively unscathed, but only because they had the great, good sense to retreat to a section of the city more hospitable to their cause. He was sentenced to four years' exile and his house pulled down, along with that of his Querini co-conspirators*.
But freak storms and feisty old ladies aside, the Venetian government had been lucky...and they knew it. The next (and heavily secured) session of the Maggior Consiglio addressed the not-new problem of efficiently responding to sudden crises. The issue was made more poignant by the fact that the Consiglio's exclusivity--which would only increase over the years, as the sons of noble fathers born to "commoner" mothers would be barred--set off a scramble to prove eligibility...and thus swelled its ranks.
Their solution was to streamline the handling of time-sensitive business (such as rooting out conspirators) by appointing the tribunal known as the Council of Ten. (A misnomer, by the bye: The Doge plus six more elected officials brought the effective head-count up to seventeen.) True to the Venetian phobia of autocracy, checks and balances were baked in from the get-go: Terms were limited. Multiple members of the same family could not sit on the Council at the same time. To prevent a single person from wielding too much power, it had three "captains," rather than one, and their terms were fixed at a single month. Additionally, "captains" could not go out in public where they could be bribed or listen to accusations that were not vetted by the entire Council. And as the ultimate safeguard, the lifespan of the Council was set at two months.
As my Gentle Reader will doubtlessly be unsurprised to learn, that last fail-safe didn't quite work out as planned. A clause allowing for two-month extensions to its mandate was invoked again...and again...and again...and the fiction of "extension" recurred for another two dozen years until the Council's permanency was made law in 1334. Its term expired only with the Republic itself in 1797.
Do the math: An "emergency" two-month response to a specific crisis lasted very nearly half a millennium. During those five centuries, the Ten took on increasing power as, among other things, Venice's spy agency, secret police, Dept. of Defence, and diplomatic corps. Also unsurprisingly, its secrecy and utter non-accountability earned it a sinister reputation, within Venice and western Europe at large.
In fairness, the Ten's efficiency to a large degree justified their extraordinary powers. Checks and balances were kept, and even increased. Alas, these became increasingly meaningless. Two and a half centuries after permanently legalising the Council, even the Maggiore Consiglio was scarcely capable of exempting review of its own laws by the Council...and little else. As La Serenissima glided into the dolce far niente era roughly (and ignominiously) ended by Napoleon, the Ten's corruption was merely one tumour in the larger cancer eating the Republic.
Yet as much as historians so often succumb to an over-dramatic tendency to hang their story around those at the very apex of society, in this case I consider that dangerous. History is not biography, unless it's in a very collective sense. And that's what makes the events of seven hundred years ago and (for me, anyway) a continent away such a very modern tale.
- Increasing concentration of power in hands that already hold much of it
- Politicians willing to divide--even at the risk of being conquered
- Those at the top of the social pecking order arrogantly treating the state as their private property...including as a weapon in their own feuds
- Those nearer the bottom of the pecking order not uniting (and raising Hades) to stop their government from becoming a country club
- Elective wars (including a for-profit one that destablised an entire region)
- Government using a temporary crisis (self-inflicted or not) to justify a permanent power-grab
Technology, true, is occasionally a bona-fide game-changer (although, it turns out, this happens less frequently than you'd think...and certainly doesn't live up to predictions). But the human condition has been fairly immutable over the centuries. Our biggest mistake in the West has been to think of our hothouse as the world and then freak out when an outside stone smashes a window. And our second-biggest mistake is to deny that the stone bears our fingerprints (e.g. al-Quaeda, Daesh, the Taliban).
Ignorance of 13th/14th century Venetian history is perfectly understandable (unless, of course, you're a nerd that way). But ignorance of recent history is inexcusable. Most especially when we allow our soi-dissant "leaders" to let past missteps point the way further down the wrong path.
- - - - -
* A somewhat ridiculous coda occurred when the Querini house was found to be co-owned by three brothers, one of which had had absolutely nothing to do with his guilty siblings. Because destroying only two-thirds of the house proved problematic, the Venetian government sensibly (and fairly) bought out his share and then razed the structure. History can be goofy like that.
- - - - -
Bibliography:
- Norwich, John Julius, A History of Venice, New York, NY: Vintage Books, 1989
- Biography.com: http://www.biography.com/people/john-cabot-9234057#north-american-voyages
- Digplanet: http://www.digplanet.com/wiki/Council_of_Ten
- Wikipedia: https://en.wikipedia.org/wiki/Pietro_Gradenigo and https://en.wikipedia.org/wiki/Council_of_Ten
Thursday, October 22, 2015
Quality isn't just another value-add
Previously, I mentioned that the Q-and-A period at this past Tuesday's Moncton User Group meeting ("Security Enterprise Architecture for Developers") basically resulted in two epiphanies for me. The first, and more junior, one I riffed on during the previous entry.
My question to Jamie Rees had to do with "selling" security's value to your client as part of the application development process. (Because we all know we should make apps. secure from the ground up, right? But, then, we also know that we're supposed to floss every night, too. And we all know how that plays out for most people. Your faithful blogger included.)
I was thinking of I/T security in terms of risk management. To wit: A data breach costs money. If data related to financial information (credit card numbers, Social Security / Social Insurance numbers, bank account numbers), the company whose data was leaked is typically on the hook for years of credit monitoring for each person affected.
Then there are the lump-sum costs. Things like the hit to customer goodwill (which sounds really squishy, but there are accountants who specialise in quantifying that in hard cash). Finding and patching the weaknesses in the system does not come cheap either. Depending on the industry, third-party audits might be required. And if the security lapses were super-egregious, heads will roll, which entails (at a minimum) the costs of hiring and training.
So I figured that this could be gelled down to a simple formula:
If that "annual risk" (quantified in dollars) is greater than the budgeted amount for security in the Statement of Work, it should be a no-brainer, right?
Jamie Rees had a few thoughts and suggestions, including the nugget that in security more than anything else, you have to protect yourself from entropy. Because waiting until a crisis to fix a hole means that you will focus on that crisis alone. But once that energy's expended, organisational fatigue will guarantee that there will few (if any) resources spent on proactively preventing the next crisis. (Sound familiar?)
But as I was digesting this all down for my notes, someone else raised a hand and asked the question as it should have been phrased in the first place: "How do I sell my clients on security without selling fear?" And, wham! Synapses linked up, proverbial light bulbs went on. (For all I know, the heavens opened to the sound of angel-choirs. But Suite 201 of the Venn Centre is really, really well-soundproofed, so don't quote me on that.)
For the record, Mr. Rees's answer boiled down to mapping security to the project goals. (Like, I might add, y'do for everything. We're All About the goals, not the features here.)
But what hit me was security, really, is just another facet of Quality Assurance. A very specific facet, it's true--and one perhaps almost large enough to overshadow its general category.
But the thing that's Quality Assurance has proven over and over since Dr. Deming pioneered the discipline is that quality ultimately pays for itself. Namely, because focusing on quality forces you to take a hard look at your organisation and its processes. A relentless focus on quality allows far less room for the politics of personality--which includes the always-regretable "rock star" culture. And it has no mercy for the "But we've always done it that way" argument.
So, when pitching my services to future clients, you can bet that I will be pointing out how developing an application for their business buys them process consulting from an unbiased 3rd party as part of the package. And all for the low, low cost of higher quality. :~)
My question to Jamie Rees had to do with "selling" security's value to your client as part of the application development process. (Because we all know we should make apps. secure from the ground up, right? But, then, we also know that we're supposed to floss every night, too. And we all know how that plays out for most people. Your faithful blogger included.)
I was thinking of I/T security in terms of risk management. To wit: A data breach costs money. If data related to financial information (credit card numbers, Social Security / Social Insurance numbers, bank account numbers), the company whose data was leaked is typically on the hook for years of credit monitoring for each person affected.
Then there are the lump-sum costs. Things like the hit to customer goodwill (which sounds really squishy, but there are accountants who specialise in quantifying that in hard cash). Finding and patching the weaknesses in the system does not come cheap either. Depending on the industry, third-party audits might be required. And if the security lapses were super-egregious, heads will roll, which entails (at a minimum) the costs of hiring and training.
So I figured that this could be gelled down to a simple formula:
Average cost per breach * Likelihood of breach per year = Annual risk
If that "annual risk" (quantified in dollars) is greater than the budgeted amount for security in the Statement of Work, it should be a no-brainer, right?
Jamie Rees had a few thoughts and suggestions, including the nugget that in security more than anything else, you have to protect yourself from entropy. Because waiting until a crisis to fix a hole means that you will focus on that crisis alone. But once that energy's expended, organisational fatigue will guarantee that there will few (if any) resources spent on proactively preventing the next crisis. (Sound familiar?)
But as I was digesting this all down for my notes, someone else raised a hand and asked the question as it should have been phrased in the first place: "How do I sell my clients on security without selling fear?" And, wham! Synapses linked up, proverbial light bulbs went on. (For all I know, the heavens opened to the sound of angel-choirs. But Suite 201 of the Venn Centre is really, really well-soundproofed, so don't quote me on that.)
For the record, Mr. Rees's answer boiled down to mapping security to the project goals. (Like, I might add, y'do for everything. We're All About the goals, not the features here.)
But what hit me was security, really, is just another facet of Quality Assurance. A very specific facet, it's true--and one perhaps almost large enough to overshadow its general category.
But the thing that's Quality Assurance has proven over and over since Dr. Deming pioneered the discipline is that quality ultimately pays for itself. Namely, because focusing on quality forces you to take a hard look at your organisation and its processes. A relentless focus on quality allows far less room for the politics of personality--which includes the always-regretable "rock star" culture. And it has no mercy for the "But we've always done it that way" argument.
So, when pitching my services to future clients, you can bet that I will be pointing out how developing an application for their business buys them process consulting from an unbiased 3rd party as part of the package. And all for the low, low cost of higher quality. :~)
Wednesday, October 21, 2015
When questions >= answers
So October's meeting of the Moncton User Group (@monctonug) was a bit different from the usual classroom-esque schtick. Granted, the presenter gave a prepared spiel, followed by a Q&A period. But, thanks to technical difficulties (i.e. the wrong laptop connectors), there was no PowerPoint. Which can be a good thing, and in this case drove the content more into the realm of "war stories."
But I had two epiphanies, one small, and another not-so-wee. Because I need to mop up some things before decamping for a meeting, I'm going to just focus on the wee one.
Anyone who's ever attended a conference (other than to collect tchotchkes and gawp at booth-babes...or just play hooky on the company tab) knows that the presentations are the hamburger patty, but everything else is the bun and toppings. In other words, you don't just eat the patty. (Not unless you have a lot of food allergies, I suppose.)
Naturally, the networking is a big deal. But so's the chance to pull the content of the presentation into your own context. Normally that's done through Q&A. But sometimes, as I discovered last evening, someone else's question is even more clarifying that your own. Which is exactly when someone (with a lot more business development experience than I currently have) followed up my question with, frankly, the one I should have asked in the first place. I don't like using the phrase "refined my thinking" because I think it's usually a fig leaf for "why didn't I think of that?" Mind you, that's actually what happened, but it triggered a whole new riff in my head.
That riff is the subject of the next post. But I thought that this insight might encourage folks to click that EventBrite link the next time they're sitting on the fence about a learning opportunity. Remember, the burger is more than the patty. You're there for the burger.
But I had two epiphanies, one small, and another not-so-wee. Because I need to mop up some things before decamping for a meeting, I'm going to just focus on the wee one.
Anyone who's ever attended a conference (other than to collect tchotchkes and gawp at booth-babes...or just play hooky on the company tab) knows that the presentations are the hamburger patty, but everything else is the bun and toppings. In other words, you don't just eat the patty. (Not unless you have a lot of food allergies, I suppose.)
Naturally, the networking is a big deal. But so's the chance to pull the content of the presentation into your own context. Normally that's done through Q&A. But sometimes, as I discovered last evening, someone else's question is even more clarifying that your own. Which is exactly when someone (with a lot more business development experience than I currently have) followed up my question with, frankly, the one I should have asked in the first place. I don't like using the phrase "refined my thinking" because I think it's usually a fig leaf for "why didn't I think of that?" Mind you, that's actually what happened, but it triggered a whole new riff in my head.
That riff is the subject of the next post. But I thought that this insight might encourage folks to click that EventBrite link the next time they're sitting on the fence about a learning opportunity. Remember, the burger is more than the patty. You're there for the burger.
Friday, October 16, 2015
A red, green, and blue silver lining
The Arduino platform was created more for design students than professional code-slingers. Which is cool -- that's a noble rationale, actually. But it comes back to bite in one way. See, the folks who adapted its (C++-ish) programming language from the Java-ish "Processing" language aren't really able to support one reality of the modern programmers life. And that's unit-testing.
Again, I'm not criticising, because as it turns out, it's sort of a net win.
But first some background/terminology for non-programmers. "Unit testing" is the act of testing the smallest possible chunks of one's code. In modern development environments, you tend to write a function hand-in-glove with its test. The test defines what the expected outcome is for any inputs set. Then you (or some more automated process) runs the test against your actual code and verifies that the function did what it was expected to do.
(Aside: Later during the application development process, there are other forms of testing, such as integration testing--did your feature break somebody else's function?--plus performance-testing, and vulnerability scans, etc. For the purposes of this blog item, we're only focusing on unit-testing.)
In the Arduino world, which relies on the micro-controller taking input from physical sensors, or outputting to physical widgets, simulating that in software would be a boil-the-ocean endeavour. That's mainly due to ever-growing number of widgets that are compatible with the Arduino. For a community-supported foundation running on the proverbial shoe-string, that's too much to ask. And, in any case, I think I can safely say that the community would muuuuuuch prefer to see those limited resources devoted to the core platform.
So for a complex project that involves multiple widgets, one solution is to write your code as separate projects, test it in a more atomic (meaning indivisible) fashion, and roll the tested code into the master project. For example, my "master" project is a lighting system for the Office Finches. There are a number of elements that go into that:
Normally, having multiple copies of the same functionality is frowned-upon in software development. The reason being that it means that you have to remember to deploy bug fixes or improvements across those copies, which costs time for the coders as well as the testers.
But in this case, I rarely modify the "test" copies of the code once they're verified and rolled into the master project. Which leaves me with bite-sized bits of single-function code that can be used as reference for (or imported lock-stock-and-barrel into future projects. As long as I name them descriptively and document the functionality (which of course I do--'cuz that's how we roll chez fivechimera), it's All Good.
In this case, what I'd normally consider a "primitive" lack of testing infrastructure turns out to be a net win. It's another one of those things they don't teach you in Programmer School. That's not the point, after all--their job is to mold you into a cog that can be plugged into the machinery...at least for the first year or three. But eventually, you figure out when and where "the rules" can (productively) be broken. That's one of those career inflection-points where you slough off another bit of your "programmer" skin to reveal the "software developer" underneath.
Again, I'm not criticising, because as it turns out, it's sort of a net win.
But first some background/terminology for non-programmers. "Unit testing" is the act of testing the smallest possible chunks of one's code. In modern development environments, you tend to write a function hand-in-glove with its test. The test defines what the expected outcome is for any inputs set. Then you (or some more automated process) runs the test against your actual code and verifies that the function did what it was expected to do.
(Aside: Later during the application development process, there are other forms of testing, such as integration testing--did your feature break somebody else's function?--plus performance-testing, and vulnerability scans, etc. For the purposes of this blog item, we're only focusing on unit-testing.)
In the Arduino world, which relies on the micro-controller taking input from physical sensors, or outputting to physical widgets, simulating that in software would be a boil-the-ocean endeavour. That's mainly due to ever-growing number of widgets that are compatible with the Arduino. For a community-supported foundation running on the proverbial shoe-string, that's too much to ask. And, in any case, I think I can safely say that the community would muuuuuuch prefer to see those limited resources devoted to the core platform.
So for a complex project that involves multiple widgets, one solution is to write your code as separate projects, test it in a more atomic (meaning indivisible) fashion, and roll the tested code into the master project. For example, my "master" project is a lighting system for the Office Finches. There are a number of elements that go into that:
- Two sets of bright white LEDs that are controlled by an integrated circuit because the Arduino itself doesn't have enough "pins," (i.e., input/output ports) for the number of lights needed.
- One triplet of red, blue, and green lights that can fade in and out. With 256 possible brightnesses available for each LED, this comes out to over 16.7 million combinations of red, green, and blue. The idea is to gradually fade these colours in and out to compensate for the lack of full-spectrum daylight.
- A real-time clock to determine what time it is to turn the
lights on in the morning and when to turn them off at night. (The
Arduino, having a fairly primitive microcontroller, does not have an
internal clock in the sense that we know it.)
A passive infrared sensor that is activated (only in the dark) to determine whether one (or more) of the Office Finches has fallen off her/his perch. - One triplet of "soft" white LEDs to be used as an "emergency" night-light. They are gradually raised if motion is detected by the infrared sensor over a few seconds, and gradually lowered when the finches have settled back in.
- A photo-sensitive resistor to determine whether it's dark enough to warrant the emergency night-lighting.
Normally, having multiple copies of the same functionality is frowned-upon in software development. The reason being that it means that you have to remember to deploy bug fixes or improvements across those copies, which costs time for the coders as well as the testers.
But in this case, I rarely modify the "test" copies of the code once they're verified and rolled into the master project. Which leaves me with bite-sized bits of single-function code that can be used as reference for (or imported lock-stock-and-barrel into future projects. As long as I name them descriptively and document the functionality (which of course I do--'cuz that's how we roll chez fivechimera), it's All Good.
In this case, what I'd normally consider a "primitive" lack of testing infrastructure turns out to be a net win. It's another one of those things they don't teach you in Programmer School. That's not the point, after all--their job is to mold you into a cog that can be plugged into the machinery...at least for the first year or three. But eventually, you figure out when and where "the rules" can (productively) be broken. That's one of those career inflection-points where you slough off another bit of your "programmer" skin to reveal the "software developer" underneath.
Tuesday, October 13, 2015
Sax and Violins
Okay, not really. No violins, anyway. But Dennis did follow through on his persistent whim of taking up the saxophone. Last week he picked up a used one and just now is starting to get a feel for the reed and stops. "What's the 'Stairway to Heaven' of the sax?" I wondered out loud as he was assembling the sax and clipping on the neck-strap.
Neither of us had a good answer. Which at first surprised me--I mean, doesn't every instrument have its own Stairway? For instance, the piano has "The Entertainer." Drums have the solo from "Inna Godda Da Vida"; the harp has "The March of Brian Boru," and bagpipes "Scotland the Brave." But nothing comes to mind (my mind, anyway) as the calling-card of the saxophone. Except maybe the theme of The People's Court. Or possibly a Kenny G pastische. But, then, it's not like I could carry a tune in a two-handled bucket, so what do I know?
But then it occurred to me that, any number of non-musical skills have their own Stairway. It represents an inflection-point on the learning curve--namely, the spot where the student can start feeling confident about being competent. Unsurprisingly, a software developer is no different in that respect. Particularly when the developer can expect to be in perpetual student mode, scrambling up at least one learning curve at any given time.
For instance, in mainframe-based systems (meaning text-only terminals--or, even more retro--green-bar paper), the Stairway app. was something like an accounting report crunched from flat files. (Mercifully, I haven't had the tedium of [shudder] counting columns, specifying output formats, and fretting about data overflows since Bill Clinton and Jean Chrétien were in office.)
Likewise, back in the days of Visual Basic/C++, an angel got its wings when you deployed a multi-form app. that shuttled data back and forth to some sort of permanent storage. (Alternatively, outside the Microsoft Universe, it likely involved Lotus Notes.) As pure client-server topologies went out of fashion in favour of the web, so (mercifully) did this skill-set (most especially debugging your way through "DLL Hell.").
Before 21st century content management systems, having a home-brew collection of HTML pages for photos of your pets, vacation photos, and a mouldering blog was the Stairway of web programming. Or, if you were coding for a business, it was an online catalogue with a shopping-cart duct-taped on. (Nowadays, in this age of Wordpress, all bets are off...but if it doesn't involveHTML5 plus jQuery and/or AJAX, you might still be a n00b.)
On the server side, the Stairway once was any database-backed application. While that's still the bread-and-butter of many developers, although with the emphasis on REST, it has more of a roll-your-own-API kind of feel to it. Double that if you're providing/fielding data that could be consumed or produced by a variety of devices.
For mobile development, it seems to be the venerable list app. with cloud storage, drag-and-drop functionality, and probably some cool icons for classification. (Disclaimer: I'm not beyond the "Hello, Android" phase m'self, so don't take my word for that.)
Database? If you're using a standard relational database, you should know your way around a stored procedure (with input and output parameters) that punches at least two of the SELECT, INSERT, UPDATE, or DELETE buttons. Bonus points for advanced use of aggregate functions, conditional sorting, or pagination of results.
And, finally, in the strange world of physical computing, things get real when you have to power at least one of your widgets with a supply that's not the Arduino / Raspberry Pi / Beaglebone / Etc. Extra credit for using interrupts or making it talk to another device that's not the PC that programmed it.
Obviously, there is a world full of other tunes to play with any instrument. And now a solar system of things (given that humans sent a camera-spaceship out to Pluto and all) for coders to work at. But just as musicians don't become (or stay!) musicians without practice, so it is with software development. (Although, significantly, I have yet to see a title like Learn the Trombone in 24 Hours in the bookstore. And, of course, there's no such thing as Autotune for programmers. Grrrrrrr.)
My point is that when you buy an album from an artist or band, you're not actually paying for the individual notes or even, really, the songs. You're paying for a bit of the inspiration that made them tackle those particular songs in the first place. You're paying off the equipment. You're paying for the collaboration of many talents. You're paying those who mentored them, either directly or indirectly. And, mostly, you're paying for countless hours of experimentation and error, for "Just one more try and we can call it a day" all-nighters, for head-banging frustration and moments of sheer hopelessness. In a word, you're buying craftsmanship (and the commitment it requires).
And, although I'm not remotely musical, that sounds remarkably like software development.
Subscribe to:
Posts (Atom)