We Shouldn't Be a Fan of Our Work

Last year, after almost a decade of circumventing rules at the day job to help people serve students better, I was moved out of the classroom and into a full-time development role to continue doing what I was doing as an instructor, but without all the cloak and dagger to make it happen. A lot of people were happy with the news, including myself. It meant that I could play a role in making something that colleagues all over the country might find value in, rather than something that just a handful of schools would use without really saying much to upper management about it. Over the last 15 months, though, I've come to dread going to work. I despise checking email. I want to be invisible on Skype all the time or, better yet, just shut the distraction down so that I can make it through the day without wanting to hurl a computer five stories to the pavement below1.

The problem is not with my colleagues. The problem is not with the endless complaints from people who storm into the little space where I do my work. Believe it or not, the problem is not even with the sound of silence from human silos within the organization who refuse to share their knowledge of the home-grown CMS my project must interface with. The problem boils down to a very fundamental issue that will never be resolved so long as I am working for someone else.

The issue is the result of an unsharable vision.

Steve Jobs and the First iPad

Way back in 2010, soon after Steve Jobs walked on stage and showed the world the iPad, I started thinking about how such a device could be used in education. By that time I had been teaching for almost three years and had the hubris to think that I could write software for a tablet that would make education easier for teachers, students, and all the support staff that are required to make a school function. Looking back at the early design sketches, I almost cringe at the naivety on display. The concepts I was dabbling with were far too similar to the way Microsoft approached tablet software in 1999.

Suffice it to say, the sketches went nowhere and I shelved the idea for a few years, revisiting the idea whenever I'd read an article about how tablets were being used in education.

Fast forward to 2013, I was asked to create a special kind of report for a new type of class that was being trialled in the area. Excel was a mainstay at the day job, and every report we gave to students or their sponsor came from this spreadsheet software. Me being me, I was one of the few people responsible for writing all of the reports in the region to ensure that every student and every sponsor would see a consistent message with consistent formatting and consistent quality. This new kind of report, though, needed something that Excel was not particularly good at without a complex series of macros. Instead, I used this opportunity to push through an idea that had been bouncing around in my head since the year before: build a data-collection website that is designed to be finger-friendly so that teachers simply tap-tap-tap their feedback and let the database do the heavy lifting.

Selling the idea was not easy, as people "just wanted an Excel report", but I used a long weekend to prototype the site and build some dummy reports. I presented it to the managers the following week, and they loved it.

This was shortly after my employer had rolled out iPads to all of the schools in a bid to make us seem more efficient and professional. Both counts failed and the project was bleeding money but, again, I had enough hubris to think that I could push through my own agenda while using company resources to solve company problems. Within six months the project had expanded to include several different types of reports, and people were generally happy with the system. A few times the project came close to being shut down when certain members of IT learned of the project2, but there was always just enough pushback from the local schools to keep the project alive.

In 2015, after a redesign of the iPad software teachers were supposed to use in class, a number of people gave up trying to use the tablets in the classroom. We still had to use them to record attendance, lesson goals, homework, and other details, but a large portion of the teaching staff gave up trying to use the tablets beyond the bare minimum. The problem was that the software was poorly designed for the job it was hired to do. The textbook application was nothing more than a frustrating PDF reader that stuttered and crashed every 15 minutes. The pedagogical tool was sluggish, hard to look at, and buried all of the student profile information, making it very difficult to learn more about students — or record updates — before walking into a classroom. Despite transitioning from paper to digital two years beforehand, people were pining for the day when we'd drop the iPads and go back to paper records. The older textbooks that made use of cassette tapes were easier to use and less embarrassing than the iPad software.

So I decided to do something about it.

Again, over a long weekend, I mocked up a new pedagogical system that would work on the tablets while making the system easier to use for teachers and staff. Information would be easier to find and filter. Textbooks would be searchable and come with custom lesson plans to help inexperienced or fatigued teachers. Reports — my specialty — would be built in to the pedagogical system meaning that teachers would spend less time writing them while students and sponsors received more data from them. In the space of four days the demo was ready and I started to show it around to people at the day job.

People loved it. Managers loved it. Even some of the students commented and said that it looked simpler. HQ, however, wouldn't hear of it. There were processes and procedures and hierarchies to obey, and I was bucking the system. They demanded it be shut down, even though there was zero student information in the system. I "conveniently forgot" to do so.

Then, in the fall of 2015, an interesting thing happened. The president of the company caught wind of these projects I was working on and asked to see them. He then asked why I "was being wasted". A week later I was approached with the opportunity to transfer to do software development in the IT department and, in March 2016, it became official. That 4-day design of the pedagogical replacement system is still being worked on and refined today, and people are generally happy with it … except when they aren't.

Back to the Problem

Earlier I said that my problem boils down to a very fundamental issue that will never be resolved so long as I am working for someone else, and this is completely accurate. I have been working quite hard on the problem of creating effective software for use in education for almost five years, the first four years of which was in near isolation where I was able to design and implement features and functions as I saw fit. When I would watch people interact with my software, I would find problems. These were often actions they would do that I never once considered, and I would go back and find a better way to support their goals while also ensuring mine were met. People would come at me with ideas or complaints, and I'd listen and find ways to make the system better for them, again ensuring that my goals for the system were not lost along the way. The way I looked at the tool was very simple: the UI is for the teachers, the printed reports are for the students, the database is for me.

By doing this I was able to create something that teachers actually liked to use. Students were happy. I had a nice database full of numbers from which to quickly answer questions from managers.

Since moving into a role with IT this has changed. People at HQ are accustomed to working with software that fights you every step of the way. Want to record someone's attendance? You'd best have 3 minutes to spare, because what used to be a circle or an X on a piece of paper needs to be infinitely more complex in the name of "security". Want to know what textbook your student will be using after they finish their current book? Go ask one of the school's support staff, because the teaching software will not let you know that information without a fight. This is the state of corporate software in the world, and the previous solutions for the iPad and schools all came from this group of people. My software with it's opposite approach to the same problems is completely alien to the way they think about the job. This isn't a criticism or a disparagement. It's a fact. They're looking at problems as A⇢B⇢C⇢…⇢Z, and I'm looking at problems as A⇢F⇢Z.

It's no wonder there is a great deal more confusion at head office than at the schools. It's no wonder that when members of the various departments in Tokyo report "bugs" in my software, it's because they're not accustomed to software understanding a person's job and performing a bunch of steps transparently on their behalf. From a big picture point of view, I completely understand this. In the heat of the moment when I'm reading that email or new issue on GitHub that has nothing to do with an actual bug and everything to do with making the software harder to use, however …

Flip that Table!

I'm too close to the project. I've invested a great deal of time and effort into making something that is designed to be used by people who really couldn't care less what the corporate interests are. That's why I invested so much time into making the UI for the people who would actually use the software rather than the people making snap decisions months after the initial decisions had already been made. This is why I call people people instead of using the same language as other people in the corporate structure. The whole thing has been designed to serve the people at the bottom of the totem pole. HQ wants things changed to serve their interests3, and I am growing tired of pushing back.

There are, of course, a lot of people that I've worked with over the last year at HQ who do understand the goals of this project and have gone to bat on my behalf more times than I can count. A lot of very smart people with very sharp insights have helped take a rough idea hammered out in 4 days through to the state it's in today. Many of them are just as frustrated with the various emails, non-issues, and Friday 5:30pm deployment cancellation calls as I am. But there's not much that can be done to change this. The vision of the project is simply too foreign at the moment for people, and the sole developer is too angry all the time to cast it in a positive light. I really need to take a step back …

… and another step …

… and one more.

Because it really doesn't make much sense to continue dreading going into work. There is a lot of good about going in, too. I like a lot of my colleagues. I like the ridiculous amount of freedom I have within the organization. I like seeing people use my software without realizing they're doing more in 30 seconds today than they did in 5 minutes last year. It's a great feeling! I just need to stop being so attached to this specific project.


  1. This would be especially bad, given that I'm using my computers at the day job.

  2. these are the same people I work with now

  3. 15 months into the project, mind you …

Good Intentions. Backwards Execution.

It seems that a lot of the freelance work I do is for people who work at a company whose IT departments get to dictate how employees do their jobs. During a recent email exchange, I was asked if it would be possible to set up WordPress on a company's local network in such a way that it was accessible inside the company, but not to the public Internet. I responded with my standard "Of course it's possible; it's just software!", and the client — a middle manager in a medium-sized business — was summarily surprised. She had been asking her IT department for years to have a WordPress installation inside the company, and had been summarily rejected without being given any reason beyond "it's not secure." If that's they're opinion, that's fine, but I find this common pattern a little concerning. At the end of the day, it shouldn't be the job of IT to tell employees of a company how to do their job, but to instead find ways to support the goals people are trying to achieve.

Something I Said to a Client In an Email

If WordPress is really so insecure that it cannot be used on a local Intranet, then how about a different blogging or CMS system? Why shut a person down — especially a manager — when they are asking for something that will make their job easier or more efficient? It boggles the mind.

I've had discussions with people who work in IT at various organizations around the planet, and the answer is almost always the same. "We are expected to keep the company's data safe, so we implement lots of rules on how systems can be used."

What a lazy approach to a serious concern. Yes, it's absolutely important that there are no data leaks or other problems that could affect the company's bottom line or put their customers at risk. This is IT's top priority. But this shouldn't come at the expense of getting work done. By simply asking a person "Why?" 5 times would be enough to better understand what the fundamental goal is, which may be sufficient to offer some other tool or mechanism. If something is truly impossible, then open communication should be used to ensure everybody understands why something is a bad idea. If a person asks for a list of all customers and their email addresses in an Excel file to store on a USB key to bring with them on a business trip, the answer should be a solid "no" with a clear explanation. Something like:

"I'd love to help you solve whatever problem you've got, but putting that much data on a USB key — even encrypted — opens the company up to too much risk. What would happen if the USB key was stolen or lost? I'm sorry. It's just not possible. Tell you what, though, why do you need this information? Maybe there's something else we can do to help you …"

There are a lot of great people who work in IT that do try to help their colleagues solve problems. I work and have worked with many. That said, it seems a disproportionate number of surly tech goofballs — for lack of a better description — seem hellbent on making sure people suffer while they play the role of king in their imaginary fiefdoms. Technology opens the doors to a lot of wonderful things. Hopefully younger IT staff will replace the angry old guard who has stood in the way of progress for so long before it's too late.

Where's Your Encryption?

Data Security - Protecting Yourself From Digital TheftImagine, if you will, having all of your money and important documents in an impenetrable safe, and that safe had a complex combination.  If the combination was forgotten, you would no longer have access to any of your money.  To think that we could so easily lose all of our savings and crucial files in an instant is downright scary.  That said, imagine having all of your money and important documents in a very secure building (ex. a bank) with strong doors, good locks, and cameras where only the people you've explicitly approved could access your locker.  Which of these two options would be the safer alternative?

I am absolutely astounded by the number of companies that have not yet learned to encrypt their sensitive data, and the number of people who think they don't need to protect their own computers from data theft.

Last week a friend and I were talking about one of his employers' computers that was reported "missing" from a satellite office in Hyogo.  On that computer was the sales records for the last ten years, a huge list of customers with every detail you could imagine, an employee list with addresses, phone numbers, and current salaries, as well as a slew of other details that would be a major concern if the computer were to fall into the wrong hands.  Luckily, the machine was found a few hours later at a coffee shop down the street from the office, and everything seemed to be intact.

But the situation begged a series of questions.

"Did anyone copy the data?" I asked.
"I don't think so, but we have no way of knowing," came the response.
"Well, the data is protected, right?"
"All of the information was stored in Access and Excel files with passwords, so they should be safe enough."
"Really?  They're safe?"
"Yes. Even if the files are copied, nobody can access the data without the passwords."
"You're right," I admitted.  "But do you know how easy it is to break Microsoft Office passwords?"
"No."
"Very easy.  I can break any Office password in less than three minutes."
"No you can't."
"Yes. I can.  Would you like me to show you?"

He nodded, and I whipped out my trusty little AspireOne.  I created an Excel file with a bunch of fake data with a quick copy/paste from my blog, then put a 31-character password on the file.  I then closed the file and asked him to grab a stopwatch.

One minute seven seconds later, an Office Password Cracking utility I had downloaded from the internet showed me in plain text what 31 characters would reveal the data locked inside the Excel file I had just created.  To make things even simpler, the application even asked if I wanted it to remove the password from the file completely.

Ah, the look on my friend's face … if only I had taken a picture.

This is not the first time that someone has told me that a company notebook had been lost or misplaced, and it sure as heck won't be the last. But, regardless of how often someone might reveal this potential PR bomb to me, I am forever dumbfounded with the lack of data encryption that seems to exist on these systems.  Heck, most of these computers are said to have fingerprint readers, but nobody seems to use them.  Why not?

Fear Is The Mind-Killer

Data EncryptionFear seems to be the biggest hurdle to the adoption of disk encryption and, to an equal extent, applications that make use of a portable database.  We fear the loss of keys, the loss of performance, and the loss of simplicity once we add encryption to our already over-complicated work processes.  We've become too comfortable with the idea that nothing will ever happen to our computers, and that people generally don't try to steal data even if they do find an unprotected laptop sitting all alone on the train or in a coffee shop.

But imagine, if you will, the worst.  We have a terrible headache one day and completely forget to pick up our bag on a crowded train, then somebody takes it home with the hope to score a free computer and to maybe make a good chunk of money selling your data on the internet to some competitors.

Will it be enough to say that we had passwords on our files? Will managers be running around wondering what more could have been done?

Data security is a lot like home security.  We should take the precautions that we can afford, use, and make sense of depending on what we want to protect.  With the number of programs that simulate an encrypted partition on a computer, I think we've reached the tipping point where ALL data should be considered sensitive and encrypted right from the word go.  Once a file is in an encrypted partition or folder, then it requires very little attention from us.  Then, even if a system is stolen, the data has a greater chance of remaining locked away.

Am I wrong? Do I take encryption too seriously?  What should be considered an "acceptable data loss prevention mechanism" for most organizations?

The Need To Be Bare

Why do companies employ IT departments?  Is it to help support the business process, or dictate it?

The Innovation Light BulbOver the last few months I've had some pretty disturbing conversations with various people about the role of the IT department within a rather large corporation here in Japan.  It seems that at this particular company, 8% of the entire workforce is employed in the IT department, but nobody has a computer that they can rely on 100% of the time.  Systems are using terribly outdated "security protocols", and the amount of paperwork required to get the simplest thing accomplished is enough to scare people into doing things the hard way, rather than a better way.

Most businesses have to react quickly to changing circumstances, make concessions, an otherwise take risks to ensure that everyone has a job to come back to the next day.  Managers have to make decisions impulsively.  The IT department in question, however, had quickly developed an arcane cocoon of policies, reviews and procedures that were guaranteed to slow any application development to a crawl, and ensure that any update of external applications was rendered next to impossible.  As a result, the programming staff quit or were absorbed into the general "IT" section to perform help-desk tasks rather than use the skills they had worked hard to learn.

The IT department at the company couldn't keep up with changes in the business, and occasionally denied the need for change.  As a result, the business processes started to suffer and sales were lost.

Hiding Innovation

I've seen some companies go to great lengths to conceal the development of key tools from their IT departments just to ensure things get done and life goes on.  Usually this is done thanks to the ubiquitous use of Microsoft Office.  Not only an office productivity tool, people will use applications like Excel and Access databases to create applications that rival the scale of full-sized corporate SQL Server databases.  Once these systems become indespensible, the IT departments will be encouraged to take the massive files and "do it right" to legitimize things or massage them for any of the various ISO and SOX policies the company might be under.

It's downright scary sometimes.

Today's corporate IT has lost the art of the quick and dirty development process.  The "duct-tape programming", if you will.  Despite all of the Agile initiatives that have been tried over the years, entire new cultures of innovation-stifling rules have been seen to evolve to keep businesses from moving faster than the changes in technology.

Let's Get Naked!

Unfortunately, I've been working on several applications for my current employer under a similar situation.  The IT department here has left the company stuck in the late 1990's, with poor security policies and insanely frustrating hoops for people to jump through just to get something as simple as access to their own email on the corporate intranet.  When IT is questioned on why everything has to be more painful than a visit to a 19th century dentist, they reply by saying that development of new systems would take years to implement and would require so much input before the first line of code was written that departments would grow tired and give up.  Under the current situation, I tend to agree.  But there is another way: Go Bare-bones.

By getting a bare-bones application running quickly, programmers could demonstrate it and get feedback from users.  From there, it would be a simple enough matter to modify and expand the system's capabilities.  This would be undoubtedly much more workable than planning every little detail in advance, and would get more buy-in from affected departments.  The problem that some IT departments have is that they think of development and change in terms of years.  In order to have an agile system that employees feel empowered by, developers need to be allowed to think in terms of weeks.

This rant isn't really about Agile methods themselves, as that's not enough to ensure the success of a business or particular department.  Heck, even the technology itself needs to change.  But, most of all, companies must once more permit themselves to create applications that are simple, temporary solutions using an architecture that encourages software changes.

Otherwise, the company may be doomed to suffer.