My good Karma (Go) for the day

A couple of weeks ago, I briefly mentioned the Karma Go, and how I intended to use it to stay connected at the 2015 PASS Summit in Seattle. The good news is that the little fella worked great inside the convention center; the better news was that the convention center had upgraded its WIFI capabilities, so my Go was unnecessary. However, something else has recently happened that may be helpful to people closer to home; Karma has recently announced that a monthly unlimited plan is now available for the Go. Speed’s capped at 5MB, which isn’t super-fast – unless you live in Jackson County, Georgia.

You see, here in Jackson County, we have only one option for broadband: Windstream DSL. When it works (as it has for me), it’s fine; I have the 12MB package, which is OK for working from home. If I have an outage, I fall back to my Go and I’m covered (that’s happened twice since I got the device in August). However, a lot of people in Jackson County pay for a service that is unreliable (to say nicely); quotes pulled from a Facebook group dedicated to Windstream issues in the county:

“Really tired of the constant outages. I’ll reset and the Internet comes back in for 2 minutes then goes right back out. It’s just awful!”

Or sometimes it works, but at speeds far less than what you’d expect

“Service today at the office [in] Pendergrass…. [(0.57 MB down/.42 MB up)] makes life interesting trying to get business done… Thank God my Ipad is ATT. “

Or sometimes they don’t show up at all

“I moved. Windstream said they’d be here today. I called at 4:30 to ask when since they haven’t called. The service rep said we were next in que and it is now 7:30. No show. How typical. Lies and the runaround. Windstream is beyond incompetent.”

Windstream was hit with a $600,000 fine by the Georgia Governor’s Office of Consumer Protection, and while the service has improved for some, many of my neighbors are still being overcharged for a service they’re not receiving. Some folks in the group had read about the new unlimited plan for Karma Go and wondered if it could be used to replace Windstream. The blog announcement for Neverstop includes this caveat:

“Can I ditch my home internet provider?

Neverstop isn’t meant to be a replacement for your home internet (yet). It’s a way to have internet anywhere, anytime. Speeds on Neverstop aren’t fast enough to be comparable to a wired home internet connection. It’s not practical for most people to use Neverstop as their only internet connection, but if you’re a light user and looking to cut down on costs, you’re welcome to give it a try. Lots of us at the Karma office are already using it as a replacement for a phone plan. Who needs minutes and texts these days?”

I thought I would help people decide for themselves; I asked the Facebook group for general locations in Jackson County where people were interested, and I headed out.

Here’s my lessons learned:

Jackson County, Georgia is bigger than I thought.

I had originally allocated an hour for my trip, but it took nearly 2 (and the starting point above is not near my house). The area is semi-rural; there’s lots of little suburban areas and towns surrounded by farms and ranches. I-85 runs through it, so cell coverage (even Sprint) is pretty good. I streamed music over the Go the entire trip, and had no hiccups; everywhere I stopped (and whenever I glanced at it), I had at least 2 bars of signal, and usually 3. In hindsight, I probably should have streamed video as a test, but overall, I think it was a fair representation of coverage.

Speed tests were good (mostly).

Below is a chart of my findings, complete with download and upload speeds. I used two different speed tests, and got comparable results from both, so I’m listing the worst speed for each spot check.

Location	Download (Mbps)	Upload (Mbps)
Durham Dr, Hoschton	5.36	2.50
Oak Grove Church, Jackson Trail, Hoschton	4.13	4.22
Jefferson Memorial Stadium, Jefferson	4.93	2.40
Real Deals, Jefferson	0.95	1.72
Brockton Loop (Far Side), Nicholson(?)	5.39	10.37
Thyatria Brockton Road, Jefferson	4.00	6.12
QuikTrip, Pendergrass	2.99	5.14
Diamond Hill Church Road, Maysville	2.46	2.87
Sims Bridge, Commerce (Banks County)	5.61	3.66

As you can see, the Karma Go on the Sprint LTE network provided broadband speeds throughout my journey, but they weren’t always high speeds. The finding near the Real Deals store concerned me, but it may have been related to where I was parked. Overall, it may be worth investigation as a replacement for home internet services within certain contexts (explained below).

Possible Pros for Karma Go – Neverstop plan

If you’re a Jackson County resident and looking to escape from the Windstream experience, the Neverstop plan has some benefits that may make it worth considering.

They offer unlimited internet connection for $50/month, capped at 5Mbps downup (I think it’s 5Mbps both ways).
The plan allows for three devices to be connected to the Internet at a given time; if a fourth device connects using the plan, one of the other ones will be disabled until the number gets back to 3.
They offer a 45 day return period for the device, which retails at $149. I don’t think that refund covers any purchased data, but if you feel like the device CAN’T replace your home internet service, will work as a reasonable backup, they let you swap plans at any time.
They also have a referral program; here’s the link to my code: https://yourkarma.com/invite/stuart4873. If you decide to purchase the device, you get $10 off, and I get a $10 credit.

Possible Cons for Karma Go – Neverstop plan

Here’s the possible problems that I see with using Karma Go as a replacement for your home broadband service:

LTE technology is based on cell service, which is usually less stable than wired connections. Given the instability of Windstream, however, I don’t know if that’s true or not. My single sample today may not accurately reflect coverage at your home; that’s why I’d recommend trying it for 30 days before dropping your old service.
A hotspot is NOT a router. This device allows you to connect a computer or other device over WiFi to the Internet, but not to each other. In other words, your devices won’t see files on each other directly; if you’ve got advanced networking needs or a lot of devices, this may not be a great fit.
1. A perk of this is that each device that’s connected gets its own 5Mbps pipeline; that pipe is not shared among your devices.
2. You may be able to purchase a router that allows you to create an internal Wifi network for your devices, and then connect over another Wifi channel to the hotspot (like this one). You’d get connectivity between your devices (and override the 3 devices connected to your Karma Go rule), but they’d all split the 5Mbps pipeline.
The company itself is young. Karma’s only been around for a few years, so there’s no telling how reliable they are. They’ve had some shipping problems and communication problems of their own, but that’s part of being a startup.

Final Thoughts: Should You Buy It?

If you’re unable to get reliable service from your provider, and you have good coverage from Sprint, and you have a limited number of network devices, it’s probably worth your time to investigate the Go as a replacement. Again, a 45 day return period gives you a lot of time to put it through its paces. I love it as a backup option (the Refuel plan), but it sounds like many of you should give it a whirl as a replacement.

2015-11-11 by Stuart Ainsworth Blogging is FUN! Gadgets 0

Reason 1234 for attending #SQLPass: The stretch

I’ve done a lousy job of encapsulating my thoughts about the Professional Association for SQL Server’s Summits for the last few years, but here’s a quick thought about one of the reasons I love this conference: the stretch.

What do I mean by stretch? It’s the exposure to new ideas, new concepts, things I may never use. It’s easy for technical people to get obsessed about our struggles of the day; we invest a lot of mental energy into figuring out problems that require immediate solutions, so we often pick educational sessions that fit into our current solution requirements (i.e. I’m having issues with ETL, so let me go pick up a few sessions on BIML). That’s satisfying, but it’s not a stretch.

The stretch is thinking about issues and problems which I don’t see ahead. It’s the creative detours, the opportunities to explore ideas that are just, well, fun to think about. There’s two benefits to this; first, by allowing the mind to wander, it actually gives me a chance to have an inspirational moment about my current issues (the “aha” moment). Second, by learning a little bit about something foreign to me, it gives me an advantage if the situation ever arises that I may need to know something about that topic (i.e. we don’t use Azure now, but we might in the future).

What’s your stretch at Summit? I’m going to squeeze in a class on R, and maybe some USQL.

#SQLPass #Summit15 Gear: My KarmaGo

Just a quick post as I’m packing up for the Professional Association for SQL Server Summit 2015; this year, I’m carrying a mobile hotspot with me: my Karma Go. Just to state the obvious, yes, I am aware that the Washington State Conference Center has free wifi. I also know that wifi gets horribly overloaded in certain areas (like the keynote rooms) when thousands of device-carrying database people begin tweeting at once. I also know that most people have hotspots on their phone, but I don’t (corporate phone; unlimited data, no sharing).

So why the Go? Besides the fact that I want to stay connected with more than just my phone, I also like the fact that it offers a reward for sharing. You see, Karma’s data plan consists of two parts:

Pay-as-you-go data. I filled up with a bunch of data (mostly to use when my home internet goes down), and I refill when I run out. No monthly subscription, so I’m not paying twice for unused Internet.
Sharing earns data. If a new user connects to my hotspot, they get 100MB of free data, and I get 100MB of data added to my account. Easy-peasy (my SSID is “Free Karma By @codegumbo”) .

Checking the coverage maps (Karma runs on Sprint LTE), it looks like I’ll have great coverage. Let’s see if I can stay connected through the keynote this year 🙂

2015-10-26 by Stuart Ainsworth Blogging is FUN! Conferences PASS Professional Development 2

Coding naked.

Me, circa 1992. This is not the most embarrassing picture of that time period.

Me, circa 1992. This is not the most embarrassing picture of me from that time period.

True story: when I was in college, I was the lead singer (if you can call it that) for a goth rock Christian rave band called Sandi’s Nightmare. I had zero musical talent, and relied solely on the strengths of my band-mate (Brad; you still rock); however, while my singing ability was dubious at best, I was pretty theatrical. We had a total of 3 awesome shows before we moved on to other things, but it was a lot of fun while it lasted. Our biggest hit was a cover of Lust Control’s Dancing Naked, a fantastic little number about David’s celebration of the ark returning; his passion and excitement overwhelmed his embarrassment.

I promise, I’m not making this stuff up; it was pretty edgy for the Bible belt of Northeast Louisiana in the early 90’s. I mean, I had an earring and everything. The point of this post (besides reveling in my musical abilities and tastes of 25 years ago) is that sometimes we just need to be naked.

Let me explain; I made choices that in hindsight are difficult to defend (like my haircut). However, there was a reason for the choice at the time, and even though it may not have been the greatest idea, I’ve learned something from every experience I had. While there are things that I would do differently if given the choice and knowledge I have today, I don’t regret many things. That’s what the metaphor of nakedness is all about; being open and honest about not only your successes, but your choices along the way. You can’t change the past, but you can learn from it.

Becoming a Naked Developer

I’ve spent most of my professional career as a SQL developer working for one company (13 years in November); I was the first developer hired by that company, and my job was to build an integration platform transforming syslog data into reports, all on a shoestring budget. I strung something together in a couple of weeks, and in the first month, I took a process that normally took two weeks to do by hand down to a day; my boss threatened to kiss me (I was flattered, but declined).

Was it pretty (the code, not the boss)? No. Was it successful? Yes.

Fast forward a couple of years to 2004: I’m a member of small team building a solution to analyze more data than I’ve ever seen in my life (terabytes of data from firewalls and Windows machines); we had to import and semantically normalize data in near-real-time. We built a solution using DTS, and then moved it to .NET and MSMQ.

Was it pretty? No. Was it successful? Yes. Part of that code is still being used today, and my company has thrived off of it. We were acquired by a larger company 8 years ago, and we’ve kept moving forward.

Every few years, we’d talk about doing a rewrite, and we’d bring in some outside expertise to evaluate what we’ve done and help us come up with a migration plan. Some consultant would come in, look at what we did, and shake their heads at us. Each time, we (the remaining original developers) would attend meeting after meeting as our code was dissected and judged; we sat naked (metaphorically) in front of a team of experts who told us everything that was wrong with the choices that we made. At the end of each visit, we’d regroup and complain about the agony of judgement. In all honesty, we would have done things differently, given our current experience (and modern technology). However, the simple truth is: we won the day. We continue to win the day.

During some of these initial code reviews, the consultants were jerks. They’d spend a lot of time bemoaning how horrid everything was; I’d be embarrassed and try to explain what I would have done differently if only I had the time. The consultants would eventually propose some complex solution that would cost hundreds of thousands of dollars to implement. Our company would consider the offer, stick it in a file somewhere, and we’d keep on keeping on. Clunky code that works is better than expensive code with the same outcome.

Over time, I learned to live with the embarrassment (as you can tell from this post); I started listening to what the consultants would say and could quickly figure out which ones had good advice, and which ones were there to just be seagulls. People that focused on solving the immediate problems were much easier to talk to than the people who wanted to rip out everything and start over. Don’t get me wrong; sometimes you need to start over, but there is a cost associated with that decision. It’s usually much easier to start where you are, rather than trying to reinvent the wheel.

What’s my point?

First and foremost, don’t dwell on your past mistakes. If you can honestly say that you built something that worked within the constraints of the time period, no matter how clunky or silly it seems now, then it was the right decision. Working software works. Laugh at it, learn from it, and let it go; repair what you can, when you can, but keep moving forward.

Second, learn to code naked. Whatever it is that you’re trying to do at the moment, share it. Open yourself up to code review, to criticism; exposure brings experience. Granted, you’ll meet some seagulls along the way, but eventually, you’ll figure out who’s there to help you grow as a developer. Foster those relationships.

Third, encourage people to grow; recognize that the same grace you desire for your coding mistakes is applicable to others as well. Be kind, be gentle, but be honest; seek to understand why they made the design choices they did, and be sensitive to the fact that if it works, it works. Sometimes we get caught up on trying to figure out the right way to do something, and ultimately end up doing nothing because it’s too difficult to implement it according to the textbook.

Life is too short to not enjoy what you do; try to share that joy without embarrassment.

THIS is the most embarrassing picture of me from that time period. I thought being an actor was the best way to meet girls… Yes, those are tights I am wearing…

2015-10-08 by Stuart Ainsworth Code Good Habits Professional Development SQLServerPedia Syndication 3

Agile Perspectives: Fixed or Variable Length Iterations

Got into a deep discussion with a colleague tonight over different approaches to Agile development (yes, I’m a geek; why do you ask?). I’m a Fixed Length Iteration kind of guy, particularly since I’ve spent most of time on the Operational side of the house recently. He’s a Variable Length Iteration fan, and I thought the arguments on both sides of the fence were compelling enough that I wanted to blog about them.

Really, I’m doing this for my adoring fans.

Actually, I’m doing this because I feel guilty about not blogging, and thought this was at least SOMETHING to warrant paying for a domain year after year.

Anyway, here’s the breakdown of the two arguments; let me start by spelling out some common assumptions. I’m assuming that you’re reading this because you have some interest in development, and more specifically, some interest in agile development. If you have those interests, then I’m also assuming that you know what an iteration is. If not, the hyperlinks in the previous statements should help educate you and steer you clear away from this blog to more fascinating subjects.

The Argument for a Fixed Length Iteration

There’s a couple different versions of the Fixed Length Iteration, based on either a calendar (January, February, etc.) or a cycle (every four weeks); the goal is to commit to a ship date, and stick to it time after time. I’m more of a fan of a calendar-based Fixed Length Iteration; the actual length of the iteration varies (February is short), but development is consistently wrapping up every month, and every month code is being shipped out the door. My reasons for supporting this model are as follows:

People are cyclical creatures. We live from paycheck to paycheck; we hate Mondays and work for the weekend. Having a fixed length cycle (with some minor variation if you based that cycle on a calendar) helps in estimating and planning what gets done and when.
A fixed cycle forces developers to think in terms of components. If you’re expected to ship working code at the end of each month, you start writing code that is bite-size, so that you can leave out pieces that aren’t finished (rather than waiting until the whole thing is done). Bite-sized code is easier to test and deploy with reduced risk.
A fixed cycle means that it’s easy to change directions without stopping development efforts. Sometimes business priorities change; a fixed length cycle allows developers to continue moving forward until the end of the iteration and change gears there. The start of a new iteration is never far away, so most businesses can wait until the next month rather than waiting till an unknown end of a sprint.

The Argument for a Variable Length Iteration

I’m trying to give this perspective a fair shake, even though I don’t subscribe to it; in a variable length iteration model allows business and development to scope out work at the beginning of an iteration and estimate a ship date regardless of the cycle or the calendar; the goal is to allow code to mature and be more stable. My friend subscribes to this model because:

Variable length iterations resemble traditional projects. There’s a scope estimate, requirements gathering, and work estimates (and traditional slippage). Most agile purists immediately scream “WATERFALL”, and there’s some truth to that, but a variable length iteration is comfortable to business. It’s like Mr. Roger’s house shoes.
They lend themselves to continual shipment of code. If the iterations are variable, developers can focus on one task from start to end, and begin to operate on separate iterative cycles; if you have a development staff of 5, you could theoretically have up to 5 separate iterations going on at the same time; when a developer finishes, they ship their contribution without waiting on the sprint to end.
This fragmentation of the iteration allows for sudden, non-disruptive change. If there are multiple iterations occurring for each independent block of code, and business needs change for one line, then only that line has to shift gears. There’s no impetus to wait; you stop where you are on the one piece, and move on to the next piece.

Your Choice?

I’d love feedback on this; as I’ve stated from the outset, I’m a fixed length iteration guy. What did I miss? Are there other benefits to the Variable Length model that I’m missing?

2015-08-11 by Stuart Ainsworth Blogging is FUN! Development SQLServerPedia Syndication 5

Three Phrases I’m Eliminating From My Vocabulary

“A good man brings good things out of the good stored up in his heart, and an evil man brings evil things out of the evil stored up in his heart. For the mouth speaks what the heart is full of.” – Luke 6:45

Been doing a lot of reflecting lately on my goals in life, and I realized that I complain. A lot. Complaining is good when it leads to change (i.e. complaining about your sibling to your mom MAY cause their behavior to change), but complaints without action just lead to bitterness. I don’t want to be bitter, so I’ve recently started getting rid of these three phrases.

“I didn’t have enough time.”

Variants of this include “I didn’t get everything done I wanted to do”, “I’m not blogging enough”, “my career’s not as far along as it should be”, and “I didn’t make MVP again? Bummer”. Don’t get me wrong, I’m not making excuses for not completing things; I’m just trying to figure out ways to not complain about it. There’s never enough time in the day to do everything, and I completed what I spent time on. If I’m not satisfied with the outcome, it’s because I made the wrong choice, not that I didn’t have enough time. The trick is to figure out what I want and choose the right path.

“I’m fat.”

My clothes don’t fit right, and I’m sitting here at a table writing this blog and polishing off a bag of Doritos. To me, exercise is waddling my way from the fridge to my chair, and I wonder why I struggle with my weight? Again, complaints without action do nothing but make you bitter. I’m reading on Facebook about how several of my friends are turning to activity to drop weight and become healthy, happy, people. Maybe the first step is to quit reading Facebook.

“I’m tired.”

Variant of phrase two, but not quite the same thing. To me, fatigue has become a synonym for boredom. Instead of enjoying the moment, I spend 15 minutes complaining about how much work it was to get involved in the moment, and I miss half of the fun. It’s natural to be tired, but it should never stand in the way of getting the most out of life.

Summary

Again, I’m not necessarily to the point of taking action to correct all of the deficiencies in my life; I am, however, just about done with griping and moaning. Life is what you make of it, and I want to make more out of mine.

2015-06-09 by Stuart Ainsworth Health Professional Development SQLServerPedia Syndication Uncategorized 0

(Personal) Kanban Myths: The Myth of The Important Task

Continuing in my efforts to chronicle myths of kanban utilization, I thought I would tackle the second biggest misconception I see surrounding kanban boards. As I discussed in my previous post, many people mistake kanban to be a process for task management, when in reality, it’s a visualization of some other process. The key takeaway is that you should spend some time making your board match your process; a kanban board should emulate your workflow, not the other way around.

So you’ve invested the time, and you now have a complex board that accurately reflects how you do work. You’re humming along, getting things done. Life is good, right?

Almost. If you’re just using a kanban board to visualize a process, there’s a temptation to accept the following:

Myth 2: Kanban is a visualization tool primarily focused on (important) task management.

This is partially true; in industrial kanban, workers may use a kanban board to keep track of individual issues as they move throughout the workflow. Managers, however, should primarily use the tool to look for opportunities to continuously improve their processes. Once your kanban board matches your process, it becomes easy to understand where bottlenecks occur (both resource allocation and/or unnecessary processes). Tuning workflow is a critical part of kanban utilization.

For personal kanban, however, managing resource allocation becomes a bit of challenge; how do you manage yourself? You’re already too busy working through your pile of stuff. Unless you can recruit other friends or family members (the Tom Sawyer approach), it’s unlikely you’ll be able to adjust resource allocation. You can, however, begin to look for opportunities to tune processes. How?

This is where the conversation has to drift away from kanban a bit; as a tool, a board allows you to visualize workflow and primarily focus on improvement, but in and of itself the measure of improvement isn’t part of the board. In other words, you can see how things work, but there’s no built in visualization for determining if something has room to improve. You have to decide what that method of improvement will be. To improve your processes, you must define the metrics for improvements. Those metrics are known more commonly as goals.

Goals are a critical component of a successful kanban implementation. For example, if you have a personal goal of “I want to lose 50 pounds in the next year”, that goal should influence your decision on which tasks to pursue (and what the priority of those tasks are). In other words, if your kanban board shows that you’re getting a lot done, but no tasks are associated with the goal of losing weight, you’ve got some room to improve your processes.

So, in summary:

Spend some time making your board match your processes (at least 30 days).
Define your goals (metrics for improvements)
Take some time to tweak your processes to align them with your goals.

Minor incremental adjustments are more likely to be adopted than sudden and swift changes (see my management notes about change curve). Kanban is a long-term tool, but can be highly effective at improving workflow.

2015-03-10 by Stuart Ainsworth Blogging is FUN! Professional Development SQLServerPedia Syndication 0

(Personal) Kanban Myths: The Myth of The Process

Recently, my friend Joe Webb has posted some great resources on Personal Kanban on his Facebook timeline. Joe’s an influential guy in the tech community (particularly the #SQLFamily), so I’ve been excited about the flurry of emails and comments regarding the adoption of Kanban techniques. I’ve been using Kanban boards for a while now at work, and it’s interesting to see the differences between Personal Kanban and “industrial” Kanban. The significant distinction between the two appears to be the impetus to “get things done” in Personal Kanban by using a very simple abstraction; in other words, start with a simple board of “To Do”, “Doing”, and “Done” and attack your task list.

I think this is a great way to get started with Kanban, but I also think that it’s easy to forget about some critical components of Lean thinking. After observing a couple of email chains from friends (and comments on Joe’s Facebook thread), I thought I’d blog about some common misconceptions of Kanban, starting with:

Myth 1: Kanban is a process to manage my task list.

This is probably the biggest trap that most people fall into when they decide to get started. The simplicity of Kanban is so appealing; just throw up a board and start moving cards left to right. Getting things done; Kanban helps you do that, right?

Sort of. Kanban is not a process; it’s a visualization of your process. The distinction may appear to be subtle, but it’s important. A simple board showing three columns (i.e., “To Do”, “Doing”, and “Done) assumes that your method of handling tasks is equally simple. Your process should drive your board, not the other way around. While the act of defining tasks will yield some immediate benefits, oversimplifying the visualization has some costs.

As a concrete example, let’s assume that one of your tasks is to call and make an appointment with your doctor. You move the card to the Doing pile, call your doctor, and then get informed that they’ll have to call you back. Can you move the card to Done? You haven’t made the appointment. Do you leave the card in Doing? Are you doing anything with it besides waiting? Do you move it back to To Do? You’ve already started working. If your board is driving your process, the temptation is to leave the board alone and struggle with task movement. If your process is driving your board, you change the board. Add a column for waiting tasks, move the card, and then revisit that pile as needed.

Don’t get me wrong; starting with a simple board is a GREAT way to get started with the fundamentals of visualizing workflow, especially if you don’t know what your process is yet. However, as you discover more about the way you work, don’t try to change the process (at first); make sure that you spend some time developing your board so that it matches the way you do work. Improvement will come later.

2015-03-04 by Stuart Ainsworth Professional Development SQLServerPedia Syndication 3

Pleased to be a Friend of Redgate Again!

Just got my email this morning stating that I’ve been accepted again as a Friend of Redgate for 2015; very honored to be a part of this program again, and excited to continue contributing to the community in this way.

2015-01-23 by Stuart Ainsworth Blogging is FUN! SQLServerPedia Syndication 0