Paul C. Williams

Interfacing Technology & Business
View Paul Williams's profile on LinkedIn
StackOverflow
 3.3k 

Friday, November 29, 2013

The Long Tail of Making Things Work

There's been quite a bit of news circulating these days about worms or other malware that is starting to exploit what we have started calling the Internet of Things.

The Internet of Things is a confusing enough concept.  Everything from your fridge to your thermostat to your TV and all the points in between like routers and VoIP bridges are connected to the internet, and most of them run Linux.  These devices -- which without doubt make our lives better -- make our home networks as juicy targets as big corporate networks, but a lot softer.  Be honest with us: have you gone to the lengths to harden your home network?

The Long Tail of Making Things Work

What happens after a company has made a product?

Of course, they sell it.  

In a corporate environment, as customers we demand a certain level of maintenance.  This maintenance ensures that the firmware for our WiFi routers and other appliances is updated with the latest patches and bug fixes. People have their jobs on the line to make sure that security threats are mitigated.  We pay, on average, 18% of the purchase price annually to make sure software and firmware is up to date.  When the hardware is no longer viable and cannot be reliably updated, it is replaced, often at great expense.

This maintenance, to keep things working and safe over time is the Long Tail. It's an immense amount of work that never, ever stops. 

This differs from the home market in a radical way. In the home market, we are used to microwaves, clothes driers and TVs which we purchase once and never pay for again. We would refuse to pay $180 every year to update the TV's software; and so it stays the same.  Issues that were discovered, exploited and solved will be ignored for these devices, for the manufacturers will spend their energy on development of the next new product that will garner revenue, not the last generation which consumers will not pay to update.

DDOS Fodder

These devices, with security holes in time mapped like the catacombs under Paris or Rome, are the platforms which are used to launch a DDOS attack against whatever hapless business runs afoul of some extortionist scheme. Yes, your old Linksys router might be one of ten million devices, sending 3 requests per second against a specific Yahoo server to disrupt some service.  You will never know, of course, because the traffic is so light for any one device that the additional bandwidth gets lost in the noise of YouTube and Google Docs.

Avoid the Trap

Some consumer electronics companies avoid the trap. Among consumer electronics manufacturers, Apple has the best record of keeping software up to date, by using the same software base for 3-4 generations of devices, and making it harder to avoid updating than it is to just update your software.

Others, like printers or WiFi router manufacturers do not succeed as well. These devices languish on the desktops and in the closets of homes and small businesses everywhere, ripe for exploitation.

Friends, I implore you: DO NOT BECOME AN ACCIDENTAL PARTICIPANT!

Be picky.  Choose your devices not for their current updates or implementation of the newest 802.11 abcgn-mouse protocol; rather make sure that you've looked at some 3rd party controller firmware for whatever device you have. 3rd party firmware does not need to justify to shareholders why it is spending 18% of revenue on maintenance of legacy platforms .. it can be worked on and kept up to date just because its fun to do so.

And, of course, disable any outside access to your networks.  You don't need it.  Really.

3rd Party Firmware

Wednesday, November 27, 2013

Which technology is better: X or Y?

I always wonder why these kinds of arguments exist. Technology exists to solve problems, and at any given time a particular technology tool may solve a problem.

In reality, the question which will get answered isn't "What is better: X or Y?" but "What do you find more fun: X or Y?"

So, the question to ask is not "What is better: X or Y?" Instead, we should ask: will X solve my problem faster than Y, or will Y be better than X today.

The factors involved in this analysis vary from project to project, but should include the following:
  1. Is there prior art that can be leveraged in either X or Y, so that I have less work to do to get to market?
  2. Do I or my existing team have an existing competency in X or Y that I can leverage?
  3. Given my existing knowledge, in which technology X or Y will I more rapidly be able to make changes?
  4. When I need to hire assistants, will I more readily find help with X or Y, and will that help be at the level I need?
The answers will be unique to you, and defined by your existing experience, and the experience of those around you.

Big companies are not the only entities with "legacy" infrastructure -- we all have a tyranny of legacy to contend with. It's important to partner with your personal legacy and co-opt your legacy for your purpose, rather than force something radical to change because someone thought that X was better than Y; for someday, Z will be better yet.

Image courtesy of Bill Longshaw at FreeDigitalPhotos.net

Monday, November 25, 2013

Innovation Expanded

Over the last week or so, I've been reading "The Idea Factory", which is an interesting collection of stories about the evolution of Bell Labs.  I find these stories interesting, because it gives us insight about how the creative process works in a technological skunk works.

Right now the stories are focused on the development of solid-state transistors. In the late 40s and early 50s these devices could be reliably manufactured, but nobody really knew what to do with them.

I think we should all be able to agree that the invention of the solid-state transistor is an innovation of the most important kind.  But, to my astonishment, no!  According to the book, the technologists at Bell Labs did not believe that was so ... yet:
...Innovation was not a simple action but “a total process” of interrelated parts. “It is not just the discovery of new phenomena, nor the development of a new product or manufacturing technique, nor the creation of a new market,” he later wrote. “Rather, the process is all these things acting together in an integrated way toward a common industrial goal.”
...A Bell Labs development scientist named Eugene Gordon, points out that there were two corollaries to Morton’s view of innovation: The first is that if you haven’t manufactured the new thing in substantial quantities, you have not innovated; the second is that if you haven’t found a market to sell the product, you have not innovated.
This has really impacted how I think about innovation.  I used to think it was all about creation, but in this light it is also about production and dissemination.  These are different parts of the product life cycle, but truthfully must be incorporated into an innovation process before adoption can occur.

Image courtesy of Janaka Dharmasena at FreeDigitalPhotos.net

A strategy lesson from my wife

My wife is a constant stream of wisdom. She mentioned this to me the other night, before we were off to a weekend visit to Wyoming, and had a few house chores left. It is an instant introduction to strategy and tactics in prioritizing tasks.

Tactics: If you want the kids to fold their own laundry, make sure that's done first.  Make sure tomorrow's clothes are in today's laundry.

Strategy: Do the whites before bed.  If you're too tired to finish, you can leave them in the drier.

The take away here: Unblock others. Identify what tasks are required soonest. Figure out what can wait and do that last.  Finally, make sure your tactics and strategy don't work against each other. Don't do the whites last if you really need that white shirt for tomorrow.

What business lessons have you picked up from unexpected sources?

Image courtesy of zole4 at FreeDigitalPhotos.net

Friday, November 22, 2013

Perfect Forward Security : Making bad guys work harder for your data

Every Solution Architect needs to be familiar with the state of data security technology. There is so much innovation in this space, it's hard to keep up.  The advent of elliptic curve encryption has reduce the computing cost of generating high quality keys.  Now the application of "perfect forward security" takes that to the next level, by introducing a protocol for generating session keys to prevent a single compromised key from allowing large quantities of data to be decrypted.

It's math heavy, but if you design secure systems, or are responsible for sensitive data you must know this.

SSL/TLS & Perfect Forward Secrecy

Twitter just announced that they're implementing this, and describe their lessons learned.

Both are worth the read.

Decade ago; decade from now... what is the trajectory of IT?

Sometimes, it's not easy to remember what life was like 10 years ago. This article compares how IT infrastructure projects ran a decade ago, and what would be different today.

Looking back: How I'd build an IT infrastructure today versus how I did it 10 years ago

The article spends a lot of time describing how cloud services have changed the way he would have deployed his IT services.  In corporate and enterprise IT, the use of cloud services isn't quite as prevalent yet.  I wonder if this is a foreshadowing of what the next 10 years holds for corporate and enterprise.

Certainly, my kids are getting used to cloud -- much of their homework is done on Google Apps for Education. My daughter collaborates in teams on papers and presentations using Google Drive. There must be a generational influence when these kids enter the workforce.

Still, I find it hard to overcome my own bias against cloud services. Especially with the ongoing revelations of NSA snooping on cloud services, data stewardship seems to continue to be a point of friction in migrating to the cloud for enterprises.

Thursday, November 21, 2013

My 4 Favorite Technical Interview Questions

Technical interviewing questions
When I'm interviewing candidates to add to my team of Java engineers, I want to make sure that I hire smart, thoughtful, self-starters.  I don't want to spend much time training them on the basics.  I need to make sure they can write maintainable code, and they have the chops to contribute to designs.

Once I've covered the basics of java coding, like knowing the construction of classes and objects, and other typical syntax, I get into some of the "heavier" lifting.  None of these is particularly difficult to answer, but the depth of answer gives great insight into the overall competency of the individual.

After I ask these technical questions, I usually move on to interpersonal questions.  In addition to being a great technician, I've got to assess how that person is going to fit in to the team. I want the team to challenge each other, but not to the extent of causing friction. There is always room for respectful debate as long as it can be directed to closure by an effective leader.

1. What is the difference between "final", "finally", and "finalize"?

This question, besides having the virtue of a cute alliteration, is what I consider the litmus test for "journeyman" Java experience.  The identifiers seem similar based on the name, but the use is totally different. The depth to which a candidate can discuss these features can be used to infer general Java language knowledge.  This is one of the few language specific questions I ask.

The "final" identifier is used to modify methods or classes to prevent polymorphism, or to modify members or variables to prevent changes to references.  "final" does not prevent changes to content, so if you require immutability of content, there's an additional step required.

"finally" is an often omitted 3rd part of a try..catch..finally block, which is guaranteed to run upon returning from the try.  This is used to release resources (e.g. close database connections).  It is sometimes used after a try block with no catch, to execute statements when control is returned either by an immediate return or an exceptional condition.

"finalize" is a special method in an object.  Similar to a constructor, the "finalize" method is called before the object is garbage collected, and can be used to free resources.  If the Java process terminates (normally or abnormally), the "finalize" method will not be called.  The designer must not rely on the "finalize" method, because there is no guarantee it will be called.

2. What is your favorite design pattern?  What problems does it solve for you?  Under what conditions would you avoid using it?

Design patterns are a great way for software engineers to communicate tested solutions to common problems. Even if the interviewee isn't familiar with the standard design patterns, chances are that if you allow them, they can communicate some kind of typical solution. 

Great answers to this question are surprisingly hard to come by. Most of the time, the interviewee can name a couple, common to the point of cliche, like MVC for which there are already frameworks that coders can hook in with.

A great answer to this question would describe how using a Facade or Adapter pattern allowed a seamless integration between a modern and legacy system with a minimal amount of fuss by adapting the legacy business methods to the new updated APIs, but fails to help when there are processing bugs that need to be resolved, and can complicate debugging processes.

3. What is your least favorite feature of your most favorite language? How do you work around this deficiency?

This tidbit asks the candidate to dig a little deeper and show us how much they've actually done in the language of the day. We can see quickly where the candidate finds a boundary and how the candidate responds to the issue. It also gives us insight into how deep the candidate has delved into the language as a programmer, what kinds of problems the candidate is likely to have been solving, and how skillfully they work around the issues.

My favorite part about this question is that I might get an answer regarding a language that is not on the job spec sheet. When I get answers that refer to a language other than Java, I know that I've got a candidate with real potential.  I can also dig a little deeper by asking about the language they identified.  I don't have to know the language in question, but I learn a lot from their level of confidence in presenting what they know. This can also help "loosen" the conversation, because it gets them talking about something they're passionate about.

4. Tell me about your favorite project.  What makes it your favorite?  What were you most proud of? What would you have done differently?

When I interview a candidate, I look for someone who is introspective and can draw on their experiences to determine what worked well and is worth replicating, and what could be improved. This question helps me to understand the candidate's design process and competency.  It also can give some insight into the complexity of their projects and how they've managed that complexity.

What are your favorite questions, and how do they help you evaluate technical candidates?

I invite you to leave your favorite questions and criteria in the comments below.  Let's have a discussion about identifying the best talent out there for our teams.

Image courtesy of franky242 at FreeDigitalPhotos.net

Wednesday, November 20, 2013

Calling Java methods from RPG programs

Lately I've been working with a client to help them bridge a gap between their existing RPG programs and a Java utility library used to execute some network APIs.

There are a lot of resources around, but there is quite a bit of confusion about the specifics of the call semantics between the purely procedural RPG code, and the object-oriented behavior of Java code.

In Java, there's a magic identifier this, which references the current instance.  Because RPG lacks the concept of an Object-Method call, it cannot supply the reference to the object that becomes this.  Instead, when calling from RPG, a parameter is inserted before the first parameter.

As an example, given the following simple Java class:

public class Foo {
    private String bar;
    public Foo() {
        this.bar = null;
    }
    public void setBar( String bar) {
        this.bar = bar;
    }
    public String getBar() {
        return this.bar;
    }
}

The RPG to set up and execute the java method from RPG looks like this:

 * Define a prototype for the 
D fooObj          PR              O   EXTPROC(*JAVA:
D                                      'Foo':
D                                      *CONSTRUCTOR)
 * define a constructor for strings
D makestring      PR              O    EXTPROC(*JAVA:
D                                       'java.lang.String':
D                                       *CONSTRUCTOR)
D    bytes                      30A    CONST VARYING
 * Define a prototype for the setBar method from the Foo object.
D setBar          PR              O    EXTPROC(*JAVA:
D                                       'Foo':
D                                       'setBar')
D                                      CLASS(*JAVA:'java.lang.String')
D                                      CONST
 * Define a string to hold the bar parameter...
D bar             S               O    CLASS(*JAVA:'java.lang.String')
 * Define a field to hold the foo object
D fooInst         S               O    CLASS(*JAVA:'Foo')
 *
 * Define instances
 *
C                   EVAL      bar = makestring('123456789012345678901234567890')
C                   EVAL      fooInst = fooObj()
 *
 * Call the setBar method on the Foo object.  The prototype only defines
 * One parameter, but there is an implied first parameter that populates
 * the java "this" identifier.
 *
C                   EVAL      setBar(fooInst:bar)

I'm not an RPG programmer, nor do I have access to an AS/400 to test my code.  Leave me a comment if this needs to be improved and I'll be sure to make the necessary edits.

References:

Monday, November 18, 2013

I'm still waiting for Mr. Fusion...

According to NPR's science desk, there's some movement toward using cellulosic ethanol sourced from trash.  This is still a half-measure in my mind ... I'm going to hold out for Mr. Fusion.


Friday, November 15, 2013

Boss vs. Leader : Is it fair to polarize this distinction?

I saw the title image here floating around LinkedIn this morning.

There seems to be a lot of this kind of wisdom around.  I, for one, don't buy it.  It actually bugs the crap out of me.

I can agree with the Boss column.  We have all been subjected to bossy people in our lives, whether they are siblings or cousins, or just that bossy kid in our play group.  The behavior meets the criteria in the boss column.

I'm not sure I agree with the Leader column.  In the leader column we see behaviors that I ascribe more to a mentor or cheerleader.

The difference is what linguists call "code switching", or being able to fluidly shift between communication styles as required. Sometimes we apply the concept to different languages, or more recently by NPR to reference how race relations has evolved in the US.

The point is this: Leaders know what communication style to adopt for any given situation.  The most effective leaders I've worked with know when it's appropriate to say: "Yes, I hear your opinion on how we execute. However, this is my project, and I need you to execute the way I want."  According to the table above, this is a boss-like behavior, but ultimately leaders sometimes need to hold the reigns and drive a specific course.

Thursday, November 14, 2013

Feeding my internal narcissist

Hey folks! I've just designed this new site and implemented the matching skin on Blogger.  I think the effect is quite seamless.  On the main parts of my site (the profile/resume/contact links) I used a single page that switches between views on demand.  I like that there's no refresh switching between those elements.  All over I also used CSS fonts for all the textual elements -- the title, subtitle and in fact all the text displayed uses CSS fonts hosted by Google, which is much cooler than having to fire up Gimp to render a title.  I also used SVG for the header background and as many of the image elements as I could.  The entire thing is laid out using CSS, including the tilt to my profile pic on the profile page.  It's a wonderful time to design HTML-only pages.

What I'm not as certain about is my general design ability.  Being colorblind doesn't help, but I also don't have much background in User Experience design.

Mostly, my design process is to attempt to avoid having pop-out elements and oddball hover controls.

If you are someone with design sense who happens to stumble across this space, if you have a critique or comment and a moment to jot it down, please leave your thoughts in the comments space.

Thanks!

Wednesday, November 13, 2013

...On career momentum

Another good link today which addresses how to assess when you should change companies.  By Ryan Holmes I give you Stay or Go: The dilemma of when to move on in a career

I like this post, because the last words resonate with me.
And the longer you’re stuck in a position that doesn’t truly challenge you, the less likely you’ll be able to leave it.
In my view, there is no benefit to being in an un-challenging position.  The company is probably overpaying for my services, and I'm not growing my career either.  Stay too long, and any marketable skills that apply to new opportunities will rot into obsolesce.

Equally important is that there's no benefit to staying in a job where the challenges are insurmountable.

It's a Goldilocks problem -- we must be allowed to move, to make progress, to challenge but not be stopped to grow as individuals and to grow as value creators.  We have to find a place that needs us as much as we need it.

AWS Workspaces - Desktop in the cloud

This is very cool.  AWS now allows you to host a cloud desktop environment.  This is one step closer to Bob Cringely's recent prediction (and not so recent predictions) of obsolete desktops.  I will definitely be thinking about this when my next desktop update cycle hits, especially if we can start to figure out how to deal with peripheral devices like printers, USB drives, camera flash memory and largish storage (e.g. for those photos).

Update: Cringely picked up on this too, for his pet application Mainframe2.

Friday, November 8, 2013

Test!

This is a test, it is only a test.  If this were a real blog message, it would have content worth reading (or at least worth writing).