As a disclaimer, this post is mostly me reassuring myself that I shouldn’t give up computer science completely and go live as a hermit somewhere.

I was recently at a java conference. The conference was excellent. I sincerely support the idea of getting together with other technology people to discuss best practices in our field and share knowledge. It’s a great way to learn and even just understand that there are other people out there who understand what your job is like.

However, there is a risk in going to these conferences and it jumped out at me in a session on immutability.

The presenter was making the case for immutable programming which is the idea that almost none of your variables should ever be allowed to change state. The talk was good, but I find it easy to become almost frantic at sessions like this. Here’s a brief look inside of my head:

“Oh gosh…I program with so much mutability! I need to change. I need to change now! MUTABILITY MIGHT END THE WORLD!”

While it is true that programming immutably is better than programming mutably, mutable programs are not the worst thing ever. We’ve been using them for years and a lot of people will probably continue to use them for years. Immutability may be better, but it isn’t the holy grail of programming.

I imagine the same thing happened when the infamous “Go to statement considered harmful” paper came out. Yes, go to is bad. Yes, it is easy to shoot yourself in the foot. But you can also create programs with it that work. And that’s really what we need in an enterprise environment, isn’t it? Programs that work.

It’s easy to set your goal as the perfect programming style and to not be satisfied until you write everything perfectly. Sometimes you need to accept that your design isn’t the best and might require work to update later. Sometimes you need to accept that even though you’ll strive for perfection, not all of your programs will be that. And that’s ok. Make the best program you can in the time you have, learn from your mistakes (and conferences) and improve your programming style over time.

In the previous post we established that tablets are in general are a good idea for executive/VP/Management typed jobs to have so now the big question: Android, iOS, or Windows tablet?

Let’s look at these from two angles:

1. How easy is it for an IT department to get them running within a current environment?

2. How comfortable are execs using it?

For the first, windows tablets are the hands down winners (Windows, not Windows RT). Rather than incorporating a whole new operating system and purchasing expensive software to manage it, it’s just a different version. Not to say it’s plug and play, but getting windows to match corporate security standards is much easier than iOS or Android.

The second is more complex and depends on the executive. iPads are easy to use. There’s no way around it. My grandmother (who is in her mid eighties) can use it confidently. I’m not comparing VPs and managers to my grandmother….but the point stands.

Android tablets sound scary. They’re also less shiny and less well marketed than iPads. Long story short, it’s more difficult to get a non-technical person to use an android tablet.

Windows should be obvious, right? It’s what every enterprise uses. It’s common. We’ve all been using it forever. What surprised me was that it wasn’t that simple. Most execs I’ve talked to don’t want a windows tablet. I guess it’s the intangibles, because they want an (you guessed it) iPad.

Is this the right choice? The techie in me says no for the reasons above. But there is something to be said for keeping execs happy and comfortable.

My wife recently showed me an article about Miss Teen USA having her computer hacked. Let me start off by saying I konw this is a delicate subjct and I have a lot of sympathy for this lady as I know people who have gone
through similar horrible experiences. I think it is important to take a look at this incident from a technical perspective.

I’ve ready a number of articles on this incident now and they all focus on the social side of the issue and how scary it is to think that someone could be watching you through your webcam at any time and you wouldn’t know about it. After my wife showed it to me, I did a little research on how this can be done. My goal here is to dispel a little of the fear surrounding this event and explain what you can do to keep yourself safe. There are two main methods an unscrupulous person could use to do this kind of thing.

RATs

A Webpage

How can I stay safe?

….I actually don’t. I’m a Windows/Android user to the core
(unless someone offers me something for free, which has happened). But there is a trend right now in some enterprise towards the mobile world. Executives want to get their documents on an iPad, they want a company iPhone, and they think it would be a cool/trendy/effective idea for everyone else to move in that direction.

There are a couple of topics here:

1. Are tablets a good idea for execs?
2. Are iPads the right choice?
3. Are tablets right for every job?

I’ll hit the first one for now. Spoiler alert: this article won’t be useful if you’re trying to convince your boss to buy you an iPad.

Are tablets a good idea for an exec? I honestly think this is one of the few jobs they make sense. The execs at my company are highly mobile. My desk of the last year has been outside of the office of one of our VPs. I’ve gone weeks without seeing her sit at her desk, not because she’s lazy or on vacation, but because she has time to run into her office, grab the papers she needs for her next meeting, and walk back out.

For that kind of job, a laptop just doesn’t cut it. Most laptops won’t have enough battery power to last through an 8 hour day, they’ll die halfway through. They’re also very heavy (at least heavier than most tablets). If you have to carry around a charger, that adds to the weight.

If you can have a tablet or a slate that provides you with all of your papers, emails, documents, and schedules, it adds to your mobility and reduces the load you have to carry.

Add to that if you go to a lot of conferences or travel a lot, a tablet can easily have a cell data connection when wifi isn’t available.

Long story short, tablets make sense for execs and VPs. The kinds of jobs that are mostly in meetings, sending emails, and reading reports.

To shop in Sam’s club (and take advantage of their super savings) you have to purchase a membership. They check your card at the register to make sure you’re a member. Makes sense, it’s their business strategy.

But then, as you’re leaving, they check you’re receipt. Consider why they do that. Here are the possibilities I can come up with:

1. Make sure you have a valid member number

Ridiculous. They already checked your card at the register. There’s no way to pay without a valid card.

2. Make sure you aren’t stealing the cart.

Also silly. The carts are oversized. The merchandise is in bulk. Unless you can teleport, shrink the cart, or decide to knock out the employee at the door, there’s no way to steal a cart full of groceries.

3. Make sure you didn’t add some items to your cart you didn’t pay for.

This one makes the most sense, but still isn’t legit. The employees don’t look through every item in your cart to know what you are leaving the store with, nor do they read your receipt fully to know what you paid for.

Conclusion: Sam’s club pays an employee to stand at the exit, and slows you down from leaving their store to put on a good show.

I’ve posted a couple times recently about a migration project between one wiki to another and work I’ve done to create a script to move the content. I’m going to give a spoiler here: Whenever you offer to automate a part of a project and prove you
can do it, more things will get shoved into the “automate this, please” bucket.

As long as the task makes sense to automate, this is not a bad thing. It really just means that your non-programmer coworkers are starting to understand the power of programming.

“Unlimited power…of programming!”

But at some point, your simple script to automate documents moving becomes a mass of sphagetti code. It’s no longer a script, it’s a monster. And suddenly you realize you should have asked for the time to design, build, and create tests for the thing properly. Usually by this point, you’re too deep in to go back and start over. At least I am.

The script works (really well, I might add). But if someone asks for another feature or someone wants to modify it for use in another project, we’re going to have a problem. I’d like to share how I got here, and give you a few key things to watch out for to know if you’re script is becoming a monster.

At the start of the project, a simple task was described (download HTML documents and save them on a file share). Easy enough to automate.

Then, the task expanded to, “Also push them into the new wiki.” Also, not a big deal. Still pretty simple here. No red flags.

RED FLAG HERE: Because the project was in full swing when I pushed for automating the migration, there were already interns copying and pasting documents by hand. They hit a few issues with the copy and paste action and I got asked, “Could you script do a little reformating, maybe change some links, and maybe some other simple stuff?”

Watch out for these words: maybe, stuff, and simple.

None of the things they asked me to do were complicated on their own (replacing domain names in links, excluding a couple pages, only copying unique attachments, etc) but combined they made my script a monster. After hacking together a script with all of the features shoe-horned in, I was asked to do one more simple task (get a list of the attachment extensions). There was no way to work it into the current script, no easy way to exclude activities from the script, so I was done. For this new feature, I built a separate script we’ll have to run separately.

The reason to watch out for those key words is because they communicate with vagueness and leave room for things to be added and removed with little warning. If you start hearing those kinds of general, vague words or, “We’ll let you know if we need this or not”, “We’ll get you a complete list of features later” it’s important to politely communicate that if features change, you’d like some extra time to make sure the script you’re building is well designed (For this conversation, certain buzz phrases are effective and useful. Phrases like: Reusability, well engineered, software engineering life-cycle).

This is one of my longer posts, and could it be much longer still. It’s an important topic if you’re building software for a business anywhere.