Ideas for blog articles

I've intentionally avoided writing about blogging, but an article from Dosh Dosh caught my attention.

I didn't start a blog with the intention of making money. I do, however, enjoy many of Maki's articles, so I read Dosh Dosh on a regular basis.

Maki recently posted Pattern Your Audience: How Editorial Calendars Can Increase Your Readership. The main idea of the article is that patterns in our blog postings can create expectations that tend to draw people into our blogs.

This article caught my attention for two reasons. First, approximately once a week I post an article with a gadget theme. I haven't received any feedback one way or another, but I enjoy hunting for quirky gadgets.

Second, I've participated in some conversations recently on the topic of whether to blog even if one doesn't have something interesting or unique to say. Perhaps this material will provide inspiration (for myself and others) for some interesting article content.

Here's a reproduction of Maki's list of suggestions with some of my own thoughts relative to this blog.

1. Interviews - Smoothspan's Bob Warfield has some interesting interviews. It's been tempting to do something similar. I might consider something like this in the future.
   
2. Feature Story - I've considered writing some longer articles. This is another one for future consideration.
   
3. Columns - nah
   
4. Reader Quiz/Q and A - Quiz: What's the square root of blue? Hmmm... maybe not...
   
5. User Profile Highlight - I like this idea. If I do it, I might combine it with the interview idea listed earlier.
   
6. Videos/Podcasts - I've contemplated a {pod,vid}cast. My current range of topics is probably not suitable for this type of activity. Feel free to cajole me into action.
   
7. Free Reports - Sorry, this reminds me too much of my day job.
   
8. Industry Roundups - see previous item
   
9. Meme Days - this might be interesting
   
10. Reviews - If you are a vendor, feel free to contact me for information on submitting products for review. ;-)
    
11. Reader/User Polls - It's rude to refer to users as poles. Trust me, I've received correction on this.
    
12. Website Highlight - I generally prefer to post links to interesting sites.
    
13. Application Launch - Hmmm... Do architects code?
    
14. Weekly Comic Strip - Probably not - my preferred artist is somewhat busy.
    
15. Summary of Performance - only if we're talking about merit increases and yearly bonuses...
    
16. User-Submitted Content - getcherownblogdude! :-P
    
17. Monthly Contests/Deals - hmmm... perhaps this might be a way to reduce my spare parts inventory. :-)
    
18. Monthly Post Digest - nah - this brings back memories of mailing lists delivered over uucp...
    
19. Article Series - expect to see a few of these. I've recently started some mini-distro work that will be posted in a series of blog articles.
    

My pithy remarks notwithstanding, many of these are interesting ideas for creating topics for blog articles. Some readers might find some inspiration of their own.

As always, feel free to add your $0.02.

Meme for the day: everyone should have a meme for the day.

Protective Insert for Baseball Cap - because your head might not be hard enough

From Spycatcher of Knightsbridge,

Protective Insert for Baseball Cap

You can't do that on the drums!

A close friend, Michael Petiford, has joined the blogging community.

Like percussion? Have a soft spot for progressive rock?

Here's a link:

Michael's Prog Drum Blog

He's a musician, so he has the obligatory myspace page.

If you like rounds, canons, and whatnot, check out his YouTube page. He has two interesting videos in which he plays a round and a canon on the drum set.

Perl 6 and Parrot Continue to Make Progress

chromatic has posted a Perl 6 on Parrot Roadmap Update.

It's nice to see the Perl and Parrot activity continuing to move forward.

Most people have probably written Perl off as stale and past its prime. I must confess that my perlifcation has dwindled to mere personal use.

I have no interest in language wars, but I predict we'll one day wake up to find Perl once again at the top of the interest stack.

It's not dead, it's sleeping! (and I mean that in a good way)

Five Clouds? I think not...

In One Cloud, Two Clouds, Four Clouds, More?, Bob Warfield chimes in on the topic of horizontal and vertical markets for utility compute clouds.

He references an article from Om Malik in which Om makes the case for a small number of horizontally aligned compute clouds. He also references an article from Nick Carr. Nick postulates that there is still significant value to be found in vertically aligned clouds.

Each of these articles are an interesting read, well worth the time.

I agree with Bob's assessment of the near-term future for cloud computing, namely that vertical markets are still relevant as we see utility computing become an intriguing option for many situations.

There is still significant value in the ability for companies to provide compute clouds tuned to specific industries. Different regulatory landscapes, risk profiles, and preferred architectures are enough to provide differentiation across providers. Current horizontally aligned utility compute environments are not sufficiently evolved to provide simple options for the wide variety of requirements. In addition, the vertically aligned environments are predisposed to understanding the requirements and issues particular to specific industries.

Perhaps we'll see a shift once the horizontal players start to see patterns in the solutions implemented by their vertical customers, and start offering these patterns as value-added services to their vertical customers.

How much of an OS distro is necessary for a Pile of Lamps

The recent conversation on Pile of Lamps rekindled an interest from a previous life - distro engineering.

My current focus has been to select an initial set of workbench tools.

Here's my version 0.5:

• VirtualBox - I could have just as easily chosen VMWAre, but this is a home project, so economy reigns. I do want to work out the process with both products, so I've probably take a look at EasyVMX in the not too distant future. Early results confirm my original suspicions - VMWare is definitely the king of the hill, but VirtualBox does nicely for now.
  
• T2 - This is a recent discovery. It's a fork of Rock Linux. They provide a nice system development environment well suited for building distributions.
  

I can hear it now.

"But we already have gabillions of distros -don't even think about building another one!"

Hurrumph...

Like blogs, there can never be too many distros. :-)

Call it my take on Just Enough OS.

Much of what is contained in most distros is excess baggage, catering to an audience wanting all manner of doodads. Granted, there are minimalist distros, stripped down to a bare bones environment. My primary issue with these is that they tend to be focused on squeezing as much functionality into as small a space as possible. The problem space for Pile of Lamps appears to be different.

For Pile of Lamps, or JeOS, the key design goal should be to remove as much complexity as possible. The dramatic increase in the apparent number of running machines compounds the the problem of system management. Perhaps an appropriate solution is to strip the base installation to a bare minimum. Here's a quick list of the more obvious benefits.

• Less to upgrade
• Less to configure
  
• Smaller security risk footprint
• Faster to transport over the wire

In its most extreme form, the kernel's call to init could reference the end application, but there are several piddly details that make the use of init (or equiv) worth serious consideration. At any rate, these types of design trade-offs are at the heart of my little experiment.

Let me know what you think.

The Blue Monster does not appear to be going home

I just finished reading Nick Malik's Focusing on Customer 2.0. I think I've been lax in reading the material coming out of the Microsoft EA folks.

Nick's article is just shy of being a manifesto for the next generation of IT. He conjures up the compelling need to change in the modern landscape of users unwilling to tolerate the clumsy environments tolerated in the past. The IT community is once again facing an assault at the walls that protect the high priesthood.

The article references a blog posting from Gabriel Morgan enumerating Gabriel's view of Customer 2.0. Gabriel's post provides some interesting insight into how Microsoft EA is trying to frame the next generation of Microsoft, Microsoft IT (and by extension portions of corporate IT).

As I read Gabriel's article, I was struck by a gradual shift from the environmental trends, to the characteristics of Customer 2.0, and finally to the characteristics of a Software+Services business model. The final list appears to be written for Marketing types. This is not an indictment, merely an observation. I hope Gabriel's future posts on this topic speak more to directly to EAs as we collectively work out how to create architectures capable of handling this next wave of change.

Regardless of your religious affiliation, the Blue Monster does not appear to be going home.

Network Learning - A Long Pause for Good Information

I recently reread Stephen Downes' article How the Net Works, in which he articulates an excellent summary of the mechanics of network learning.

I'm particularly interested in the conditions necessary for avoiding informational cascades, or groupthink. Many of the truly interesting problems in IT cannot be solved by individuals, so network learning seems promising. However, network-derived solutions carry their own set of risks.

Stephen lists four conditions for avoiding informational cascades.

• Diversity - Did the process involve the widest possible spectrum of points of view? Did people who interpret the matter one way, and from one set of background assumptions, interact with people who approach the matter from a different perspective?
• Autonomy - Were the individual knowers contributing to the interaction of their own accord, according to their own knowledge, values and decisions, or were they acting at the behest of some external agency seeking to magnify a certain point of view through quantity rather than reason and reflection?
• Openness - Is there a mechanism that allows a given perspective to be entered into the system, to be heard and interacted with by others?
• Connectivity - Is the knowledge being produced the product of an interaction between the members, or is it a (mere) aggregation of the members' perspectives? A different type of knowledge is produced one way as opposed to the other. Just as the human mind does not determine what is seen in front of it by merely counting pixels, nor either does a process intended to create public knowledge.

Few networks can boast all of these characteristics. Indeed, as I ponder some of the networks around me, it seems few can boast more than one or two. Perhaps I'm being too cynical, or perhaps it's a sign I need better networks. :-)

On the other hand, the list provides a good diagnostic for assessing information gleaned from a network. Viewed as degrees of freedom, it's easy to see how absence of a particular characteristic might affect the output.

Also, I've rearranged the list to provide a memory aid.

• Connectivity
• Openness
• Diversity
• Autonomy

This is primarily for my benefit, but others might find it useful.

Thanksgiving

Hmmm...

As Thanksgiving winds down to an end, I'm pondering the many things to which I give thanks.

I'll spare readers the long list, but there is one thanks worth mentioning on my blog:

Thank you!

SuperCoder 2000 - because you need 011000100110100101101110011000010111001001111001

From TechEBlog - SuperCoder 2000

Siege2.0

In Enterprise 2.0 May be Fine for the Business, But what about the IT Department, Andrew McAfee writes on the "continued lack of enthusiasm" for E2.0 tools.

Meanwhile, Luke Kanies writes about USENIX 1.0, in which he laments the notable lack of Technorati tags referencing LISA 2007.

Are these related?

In my own experience, I've found many, if not most, members of enterprise IT organizations blissfully ignorant of *2.0 technologies. This might be slightly overstated, but the general level of understanding of the value of these technologies easily lags by several years. When queried regarding *2.0, a common response is a shrug of the shoulders. Many read blogs, but few understand the dynamics of the read-write web beyond the basics of forum posting. At best, many view it as a fad.¹ At worst, many are tired and beleaguered, dreading yet another salvo of technologies designed to make their life miserable.

For my part, I've recently changed my approach to *2.0 in the workplace. Instead of evangelizing and cajoling, I've simply started to mention the tools in a matter of fact way. Of course I blog. Of course I use del.icio.us. Of course I navigate a cloud of social networks across the Internet. I use them all the time. You ready for a coffee break?

1. More victims of MOA poisoning.

Change - ouch! Change - ouch!

Tom Haskins hit pay dirt again with Fallout from a system. Tom's article focuses on two primary views of change.

The first view presents change as something we do. We drive change. We focus on elements that "need" change. Tom reminds us that this view is fraught with danger. People resist change. Resistance creates conflict. Conflict creates heat loss.

The second view presents change as something that happens. It should be a by-product of our machinations. Let others identify appropriate changes to accommodate the end goal.

As Enterprise Architects, perhaps our primary goal should be to focus on articulating structures that prompt change, rather than playing into the hype of creating change. We dilute our need to foster a spirit of reflective practices.

In my own case, I readily admit to falling prey to the trap of change as a direct focus of effort. It's easy to see the results of the habit. My goal is to avoid even using the word for the next week. Wish me luck.

/me goes hunting for a "rubber band of behavior modification"

The Architecture Anti-Cabal

James McGovern replied to my questioning whether a social network of Enterprise Architects will be too insular.

James believes the opposite will happen. With the recent conversation regarding whether there is too much talk about EA Process, he could very well be right.

Here's to hoping a Wehr of Enterprise Architects can sway vendor and analyst conversations away from meta-processes and MOA, towards substantive improvements in IT and business.

Guerilla Architecture Dictionary Entry: legacy - n. the technology from last year's magazines.

Reflective Practice - An Enterprise Architecture Practice

I've recently been exploring some of the content from MIT OpenCourseWare.

I'm spending extra time watching the video files for Reflective Practice: An Approach for Expanding Your Learning Frontiers (11.965). My initial assumption was that it was learning material for improving our reflective learning skills, but it provides useful information for facilitating reflective learning.

Other Enterprise Architects might find the information helpful, particularly those interested in breaking down the walls of the ivory tower. The class provides some helpful insights and methodologies to help us interact with our constituencies. In short, people learn better when reflecting on the results of their own mistakes, not from the mistakes of others. This is deep anti-ivory-tower mojo.

I originally intended to include some examples to illustrate how the material translates to EA. Out of town visitors, however, are taking priority. Instead, I challenge EA practitioners to watch the first two sessions with an eye to analogs in their daily work. You might just find yourself making the time to watch the other sessions.

Unleash Your Lectures

Bob Warfield posted an interesting article entitled Universities Should Podcast Every Class.

In the article, Bob suggests the possibility of installing video equipment in every lecture hall, tying into class schedules, and posting the content for access by students.

For my tastes, I wish we had more efforts along the lines of the work being done by Jeff Curto.

Jeff's History of Photography podcast is an excellent example of what is possible with a very modest amount of technology. I highly recommend his lectures to anyone with a passion for photography. Those interested might also want to read Globalizing Education One Podcast at a Time, in which Jeff outlines how he creates the podcasts.

We are most definitely beyond the point where technology is the primary hindrance.

Puget Sound Information Challenge

Mark Masterson posted an article about the Puget Sound Information Challenge.

The challenge has a very audacious goal.

... to identify and share the best information resources, tools, ideas, and
contacts in their arsenal to inform the protection of the Puget Sound.
This is the challenge! The catch is that it must be done in the next 48
hours!

Quit reading this article and go there now...

A Name For High-Tech Grief

Donald Knuth wants A Name for High-Tech Grief.

On his news page, Donald poses the following question.

But what do we call the combination of helplessness and agony that affects us when our computers or computer-based appliances do inexplicable things, for which there's no apparent workaround?

He provides an initial list of candidates gathered from friends.

• cyber despair (David Eisenbud, Talin)
• technitis (Chuck McManis)
• compu-terror (Steve Diamond)
• cyber burned or cyburned (Betsy Zeller, Dave Marvit)
• digital dread (Aza Raskin)
• techno angst (Jono DiCarlo)
• irritable bit syndrome (Charles Merriam)

Donald suggests people test the list in real world situations. Perhaps a winner will emerge.

Does anyone have suggestions for additions to the list?

Here are a few off the top of my head:

• Control-Alt-Hate
• bit rage
• computermyalgia

On the other hand, this might be a non-issue. Computers are a fad.

Wooden cases - because you need more proof that trees are an important concept in programming

From SCI FI Tech,

Hand-carved wood PC

I wonder if it's available in rack-mount.

Perhaps not suffciently aloof

Techbrew posted an article on Using Feeds to Discover Human Readability.

This prompted me to run the atom feed for the Aloof Architecture blog through the Juicystudio Readability Test.

Here are the results:

• Gunning Fog Index - 11.85
• Flesch Reading Ease - 52.80
  
• Flesch-Kincaid Grade - 7.84
  

I might refresh my understanding of the metrics, if for no other reason than to understand the difference between the Fog index and the Flesch-Kincaid numbers.

Frivolous Fog food: pseudopseudohypoparathyroidism, honorificabilitudinitatibus, ethylenediaminetetraacetic acid, sesquipedalian

A Weyr of Enterprise Architects

James McGovern' article The One Hundred Enterprise Architects Meme got me thinking on the topic of collective nouns for Enterprise Architects.

A mild stab at Google uncovered

• A mystery - presumes guildsmen or tradesmen
• A glass house - yaya, keep moving
  
• A jealousy - wrong kind
  

Yawn...

Here's some low-hanging fruit off the top of my head.

• A babel
• A governance
• A 3-ring binder
  

To obvious/cliché... keep moving...

Some might suggest

• A superfluity

If you follow the EA blogosphere, how about

• A conversation

Or perhaps

• A code

...

Beyond the Dunbar Number

Stephen Downes delivered another article full of wisdom in The Personal Network Effect.

His ideas on improving the design of social networks are particularly interesting. The basic premise is that's possible to change the point of maximal value in a social network beyond the Dunbar number by increasing the diversity of the network. Highly meshed social networks tend to result in repeat messages. At a certain point, repeat messages lose all value. A diversity in our networks tends to reduce the likelihood of these repeat messages.

This caught my attention after reading The One Hundred Enterprise Architects Meme from James McGovern.

I'm curious if there is sufficient diversity in an aggregation¹ of Enterprise Architects to avoid uniformity.

1. Hmmm... collective nouns and Enterprise Architects - expect a separate posting on this topic.

Informal or Personal Learning?

Tim Hand considers the topic of informal learning vs. personal learning in Re-form(al) learning. Tim questions the use of the term 'personal learning', as it seems to be double speak in the context of learning. He suggests that 'informal learning' might be more useful.

I've been entertaining similar thoughts, but have come to a different conclusion.

I'm not particularly pleased with either term. Both seem to carry the implication of an unstructured or unfocused learning effort.

I've been wondering whether 'self-motivated learning' is a more appropriate term. I'm not completely sold, but it seems to capture the dynamic without leading the assumptive mind astray.

I'm interested in opinions others might have on the topic.

We're down and loving it!

Niall Sclater writes on a potential Downside of the small pieces model, in which he points to an outage at slideshare.

This particular statement caught my eye.

Of course institutional sites go down too - but it’s our business to keep them working and at least if services are hosted in-house we can pull out all the stops to ensure they’re fully functional.

Ummm...

This presupposes that those external sites do not have the equivalent desire to keep their services operational.

The Tower is Riddled with Networks

As part of conversation with Tom Haskins and Steve Roesler, Harold Jarche asks What business are you in?

The conversation starts with Steve Roesler descibing a life situation in which his self-employment has probably provided more options than would otherwise be available to corporate employees. In the article, he also related the gist of a conversation with an HR executive. A phrase from that conversation, "This is a business", has sparked an interesting conversation thread with Tom and Harold.

Tom enumerates several excuses offered by business for why companies wall themselves off from networks. At the heart of the concerns is a fear of losing control over their own efforts at perception management.

I particularly like one of Tom's points.

When people say "this is a business" I hear "this is not a viable network".

Harold's question asks us to look at our businesses. Are we in networks or silos?

I’ve noticed that even many so-called “new economy” companies are still based on the command & control models of the industrial age. They’re like dinosaurs wearing mammals’ clothing but they won’t be able to keep warm during the next ice age.

We are indeed creatures of habit.

For what it's worth, we also have so-called "old economy" companies with elaborate informal networks. There are, in fact, riddled with networks. We have good-old boy networks, special interest groups, rumor mills, and leaky channels to outside networks. Are they in fact mammals in disguise? Probably not, but it paints an intriguing picture.

As a change agent, my primary medium of choice is the informal internal networks. This are where conversations take place. This is where pre-emptive consensus is gained prior to gaining official sign-off. This is where the landmines are pointed out.

You got VLE in my PLE

Martin Well posted an intentionally provocative article entitled The VLE/LMS is dead.

He walks through the concept of using collections of loosely coupled 3rd party applications as an alternative to the centralized learning applications.

He is careful to point out that he's not describing a PLE. The educator is still selecting the tools.

It does seem, however, that what he describes has a strong relationship with PLEs. In fact, they are simply the server side elements many of us already use in our own PLEs.

Lessig is Moreig

Here's a link to the Larry Lessig presentation at TED.

How creativity is being strangled by the law

Kudos to Larry for providing the voice of balance regarding the current state of copyright law.

I particularly like the way he articulates the result of enforcing the antiquated model currently in use in mainstream media. We simply push the inevitable underground.

Is there a lesson here for Enterprise Architects?

I think I'll go rummage through my old mix tapes now...

Gadgets - because I need more personal organizer pr0n

Multi-tool in a credit-card form factor.

BCB Mini Work Tool

Jive Kudos

Silicon Florist posted Jive's new space should include a bigger trophy case.

It's nice to see Oregonians doing well, particularly the startups.

Democratizing Architecture Creation

Tom Haskins' poses an intriguing possibility in his Democratizing knowledge creation.

Is it possible that self-directed learners could become the norm, rather than the exception?

The article is well worth a read. In particular, this paragraph got my attention.

We previously relied on experts to fix our ignorance, superstitious beliefs and flawed models. Now it appears that the experts have the wrong idea. Expertise cannot fix our misconceptions because it operates with a flawed premise. We cannot be fixed without getting that wrong idea ourselves. We become dependent on expertise if we fall for the common misconception of learning. We create systems where learning is a noun, experts exercise their authority over us and knowledge creation is aristocratic.

In this case, the word 'expert' is used in the context of academic credentials. That flawed premise is not, however, limited to the halls of academia.

The archetypal ivory towers of Enterprise Architecture and other governance functions are particularly prone to this same thinking. It is no accident that most Enterprises struggle with understanding the value of EA. People naturally repulse from the authority of mandated truth or 'fixing' the error of their ways. I have no doubt EA people are similarly apt to be repulsed. We are talking about a fundamental shift in the value provided by experts.

The true value of expertise comes when it is available for conversation. We refine our own understanding when we expose our knowledge to others around us, so long as we allow the interaction to occur in both directions. As Tom mentions, we reflect on the differences as we engage with our surroundings.

I've noticed an interesting phenomena in the architectural conversations of my day-to-day work. As the conversations evolve, key architectural principles and constraints (stock in trade) tend to be co-opted by others around me. I hear the principles and constraints echoed in conversations around me. The organization internalizes the knowledge and is more likely to provide productive feedback when issues arise.

We're all just making it up as we go along

Harold Jarche posted School, Work & Improv, in which he mentions how his son is excited about an improvisation class.

Harold notes how the non-core school subjects end up being the most important in the long run. He lightly ponders a world where the education system consists of the electives and non-core topics. I will not opine on the education system, but I think most of the disciplines encountered in modern enterprises are sorely compromised by their failure to acknowledge the value of improvisation.

Any discipline not actively embracing the value of improvisation is, in my opinion, on the road to decay. We are deceived, whether by ourselves or by others, if we believe that all things can be planned or written down. Not all problems are solvable. Sometimes we need to fudge it. Sometimes we need to fake it. As long as we acknowledge it, it all has a tendency to work out in the end.

I've always been intrigued with the skills acquires from an intentional study of improvisation. I count what I learned in music improvisation as some of my most valued treasure.

From Domain Specific Languages to Platforms

Phil Windley posted an article on his use of Domain Specific Languages for a recent endeavor. He mentions a common reaction and goes on to describe some of the benefits he gains from using a DSL.

I find it somewhat amusing that detractors often view DSLs as unnecessary or even foolish. At the same time, we see a plethora of DSLs flowing out of standards bodies and vendors.

No matter. The classical debate continues over GPL vs. DSL continues.

While I look around at the arguments for and against DSLs, I don't see much conversation regarding what seems to me to be a wonderful capability provided by DSLs. Mapping a problem space into a DSL presents the opportunity to create a platform, rather than a mere application.

Whether open to outside contributers, or only to internal ones, the platform model provides a useful vehicle for creating an 'application' designed for enhancement, particularly if we desire a wide range of enhancements.

An explicit focus on the language-oriented discipline associated with DSLs provides a useful way to introduce critical constraints, while still leaving the door open for futures changes to the constraints.

To be sure, most level 3 platforms are in the business of providing extensible domain-specific solutions of one form or another. It's noteworthy, however, that most level 3 platforms address rather narrow sets of domains. I wonder how long it will be before we see platforms providing the ability to deliver of broad spectrum of domain languages. Perhaps we will see platforms for DSL platforms.

Meanwhile, Bob Warfield mentions DSL in his Serendipity is the Key to Code Reuse. I'm not sure if he's talking about the same thing, but we're definitely using the same language.

NeoVictorian Architecture

In Good Tech Writing, Tim Bray references a wonderful series of articles from Mark Bernstein - NeoVictorian Computing.

Marks explores the topic of why we in computing are unhappy and what we might do to rectify the situation. The series is well worth the read.

While reading the articles, my mind connected some of Mark's observations with Don Norman's needs-satisfaction curve. Perhaps we are shifting our focus to our own user experience as we cross a sufficiency point with technology.

Perhaps we would also be well served to remember that an enterprise is also a technology.

Another Day in the life of an Enterprise Architect

Mike Walker points us to A Day in the life of an Enterprise Architect.

His underlying MSDN document provides a decent summary. I must say, however, I was expecting something else upon reading the article title.

I prefer some of the quotes in the graphic on the article on his personal blog.

• Can we support this?
• What will that VP think of these decisions?
• We standardized on .Net, I'm proposing something else...
• Is this service oriented?
• How does this fit into my portfolio? 10 years down the road?

These seem to be a more accurate reflection of the title.

Here are some that have passed my ears over the years:

• Here's the 500-page spec - let me know if there are any show-stoppers by COB tomorrow.
• How long will it take to get us to CMM level 5?
• Can we avoid cabling if we install wifi everywhere?
  
• Why does the printer keep jamming?
  
• Can we do it without using swing space?
• But I can buy disks at Fry's for a lot less than that!
  
• Why is an architect worried about why we removed the coffee machine in engineering?
• Do architects code?
  

(because printers do that..)