The Memo

How many times have you done something that you shouldn’t have, out of ignorance? Have you ever went down an erroneous path because you missed some key bit of information that would have taken you in another direction? Was there ever a case where you “didn’t get the memo”?

I’m guessing a fair number of vendors and device makers in the last few years haven’t “gotten the memo” either. As a public service. I hereby present The Memo, for all of those companies doing business in the mobility space who missed it.

The Memo

We’re in the year 2014. Now that we’re moving to the age of 802.11ac, it should be noted that we’re into the fifth generation of wireless access technology as we collectively know it. WLANs are set up for client device access, and thousands upon thousands of users rely on those WLANs. If basic access doesn’t work, all of the fancy features you’ve bolted on to the wireless network are worthless.

1. This being said, the days of tolerating poorly written and tested code are over. We should all be better at this by now. Whether it’s drivers on Lenovo Ideabooks, the keychain code in Mac OSX, wireless controller code, or whatever– when it’s shitty, people suffer. Real people. Thousands and thousands of people, and the admins that support them. Developers need to partner with those of us who have our toes in reality and understand that “little mistakes” and “misjudgments” create havoc for those who are stuck with them.

So, let’s be done with catastrophic code failures, and actually start testing our code for real, okay? Like before  it goes out the door as opposed to relying on end users to find our bugs for us (usually in very unpleasant ways).

2. When a bug is found, we have the opportunity to be perceived as caring, responsible technical professionals– or complete buffoons. For large, secure, high performance expensive WLAN environments used by thousands of customers, these “recommended workarounds” do not make the author look like a caring, responsible technical professional:

  • Disable WMM
  • Don’t use enterprise security
  • Don’t use 5 GHz
  • Don’t do things that you know you have to do in a real network environment

Make this sort of recommendation to paying customers in 2014 where wireless networking is a critical service to most users, and you are casting yourself as an out-of-touch, insensitive individual who probably isn’t in the right career field. Worse, your employer sends strong signals of cluelessness. The message counts.

3. There is no line between consumer and enterprise devices anymore, at least not in the minds of end users. If you’re going to sell wireless printers and projectors, make sure they work on typical enterprise secure wireless networks. Ad hoc technologies should be killed. Any video mirroring device, TV-style streamer, wearable technology, or resident of the Internet of Things WILL find it’s way into the Enterprise, and you know it. So make them flexible enough to actually work on secure wireless networks that exceed a single Class C in size. There are only so many variants of secure wireless. Google it- and figure out how to make your products work on business Wi-Fi networks. Then go back to #1 above and make sure you test.

4.  Networks are sophisticated enough, don’t add to the administrative burden with ill-thought out management services, complex and/or frequently changing licensing paradigms, or other detractors that keep WLAN administrators away from the business of administering WLANs, Because… this is 2014 and thousands and thousands of client devices use the network and our focus should be on them and not the constant baby-sitting of ill-designed servers that violate bullet point #1 above.

5. Above all, it’s about devices being able to reliably connect on standards-based networks. Without good drivers, good code, and good protocols that were written and tested for 2014’s large critical wireless networks, the rest is bullshit. All the slick features and applications are moot if people can’t connect and stay connected. Wireless connectivity on enterprise-grade networks should be the one thing that all parties prioritize, and treat as Purpose #1.

There- now we all “got the memo.”

I realize there’s an element of preaching to the choir for those reading this blog- but for corn’s sake, we seem to have settled into a groove where we tolerate and accept failure and poor performance by vendors “because it’s wireless”, and because “wireless is complicated”. Again, bullshit I say. Do it right, or don’t do it.

5 thoughts on “The Memo

  1. Frank

    I think we all need to start printing this out and nailing it Martin Luther style to certain vendors doors, starting with whatever group at Google is responsible for the Chromecast!

  2. Devin Akin

    Preach it brother! Loved it.
    Oh, and there’s a typo: “ill-though out” should be “ill-thought-out.” Gotta check your code before release. 😉


  3. Nico D

    So I’ve been working in the industry for a while. CCIE, CWSP, CISSP etc. Helped design and configure mobility for several Fortune 100 companies, so I’ve seen the impact of poor code on networks.

    #2. Eh agreed, I wish there was a better way, but if a bug is found, you can’t expect it to be fixed fast unless it’s critical. Wireless is a very delicate balancing act, you change one thing alot of things get affected. You affect performance, scale, roaming, density, congestion…etc. So everytime a bug is fixed, it has to be validated against all the configurations that QA has on their list to validate before being released. What needs to happen is for stronger relationships between large vendors, so the slow-moving behemoths can develop streamlined methods for implementing changes and bugfixes across platforms. Some vendors like Apple play their cards close to the chest, so new code releases are only able to be tested days before it’s actually released. And, have you ever tried to tell a bunch of employee’s to not upgrade their apple device as soon as it’s released? So until we get these streamlined code/bug valet’s in the product cycle, we have to rely on workarounds or backing out changes until vendors get it right.

    #3, absolutely. Apple everyone’s looking at you. Get your product in gear and start releasing products that actually work in enterprise and not just look good. This goes for all vendors that are shipping “consumer grade” hardware, Google, Intel etc. If you want to succeed, you need to make sure it works at scale. Most of the issues I see are usually based on poor implementation of the protocol or corner case scenarios that weren’t tested in QA. This list grows daily, so don’t think it’s static. New technology brings new methods to break the code ;P

    #4, agreed. We should take a page from other vendors out there. We can have a easy to use interface that actually scales, look at Meraki, look at Apple. Having people dedicated to usability studies is paramount. Requiring an advanced degree to use the system shouldn’t be required.

    #1,#5 sure, lets make sure code is written with no bugs! Bugs are going to happen, with open standards this is always the case. Someone’s going to pee in the pool and mess with everyone else. As a wireless vendor, they need to support literally hundreds of different configuration of drivers and hardware. Plus there’s no real way to properly replicate complex environments with density, roaming, co-channel etc. There are products like veriwave out there that generate traffic, but in my testing, it’s nowhere close to the chaos I see in enterprise environments day-to-day. So I agree that everyone needs to play nicer and have better quality assurance, but at the end of the day, it’s unrealistic to expect new technology to work perfectly out of the box. So if a new vendor’s driver forgets to properly queue the traffic in the right buffer and causes issues, that’s going to happen. If we had to wait until all vendors representing infrastructure, clients and applications got their code perfect, we’d still be running 11G/11A code.

    Great memo. I’ll be forwarding this around, internally and externally. We do need some more visibility into the pains we’re facing. I think developers get in the code-churning mode and don’t really see the affect it has on customers. Y’know…customers…the people paying the bills ;P



Tell me what YOU think.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s