No Fooling Time

Every day I have a list of things to do that is longer than the day. Part of that is because I have a handful of projects all going at once that I need to move forward on. The other part of it is that I’ve always been quick at building things and I didn’t feel like time applied to me – it was this imaginary thing that I could bend at my will.

I’m still much quicker than other people’s expectations. I’ll get a project done in a fraction of the average time. But there is a bottom limit on how long something can take that I can’t get past. At that point I have to realize that I can’t squeeze more into a day than there are hours.

This is one of the hardest parts of running multiple projects at the same time, and why padding estimates is common. One project running long can affect every other project. You can easily make up that time if you have slack. Otherwise you move forward one step at a time, pushing a little harder than normal, reminding yourself that this won’t last forever.

Five Years Old

My daughter Emma was born five years ago today. It is been a bumpy five years with brain surgery on day 2, first 30 days or so in the NICU, blindness for the first 10 months or so, a hole in her heart that took years to close, eye surgery, a couple of seizures, and a few nights in the ER. Emma knows adversity.

You wouldn’t know it by looking at her though because the hard times haven’t gotten her down. Most of the time she is smiling, singing, playing her piano, or doing a combination of those. She’s been remarkably resilient, further proving to me that life is amazing and will find a way.

Happy Birthday Emma. You make this world a much better place.

Limiting Variables and Seeing Things Happen

When in the first steps of making something new I concentrate on two things, limiting the things that can go wrong and seeing something work. I start with the most simple situation possible by hard coding known good values. For example, if I’m logging a user into a system I won’t build the part to get the username and password from the user at the start. I’ll code a username and password that I know will work directly into the application. That means that if the logging in process doesn’t work that it is something wrong with the way I am sending the information rather than somehow sending the wrong information.

Hard coding those variables naturally leads to seeing things happen faster. I’m not building an entire user interface for a login screen just to be able to log in, I’m building one small piece of code that I get to see work within a few hours.

Workload

I’ve read before that the optimal number of large projects for a person to have going at the same time is 3. I can’t remember where I read that or I’d attribute them – maybe it was in The Mythical Man Month. Wherever it was I agree with it, 3 is a good number. Right now I have 6 or 7 going at the same time, depending on how you count them.

It is through no real fault of my own because a few of the projects have been dragging on for months requiring very little effort from me. But they still weigh on my mind because they are still obligations. They are worse than the other projects because they could come due at any time once the stars align in the right way.

That’s to say that I can’t give any good advice about keeping your workload light enough although I do hope that things will normalize more as our company becomes established and we get better at forecasting projects.

I do have a piece of advice about the opposite problem of not having enough to do. Make up work. Give yourself projects, there is always something to do. Don’t sit around waiting because you’ll lose your momentum.

Failing Forward

When something goes wrong in technology, like you send software out to your customers that is broken or your web server configuration breaks, you generally have two options. You can choose to restore everything to a recent known good state, reexamine what went wrong, and try again to get it right the next chance you get. Or you can find the problems that are happening now, fix them, and move forward with the new thing in place.

Neither answer is the right answer for every situation but I always try to fail forward first. Usually problems are simple enough to fix that restoring from backup will take more time. Plus, you can’t guarantee that you’ll find out why it failed the first time. Something could be different in your test environment that you didn’t think about while testing your changes.

The not-so-secret to success is to set yourself up for success. Know as much as possible about the systems you are working with. Know how they interact with every other system. Know what could go wrong. Most of all, know your fundamentals. If you are migrating a web server then you need to know how the entire HTTP stack works. Without all that knowledge you’ll be guessing at solutions rather than making smart decisions.

Growing Is Painful

I’m six and a half feet tall so it always felt like I was in a growth spurt as a kid. Painful shin splints became normal. I’m glad I’m past that point in my life.

As we get older and finish growing physically I think it is easy to forget that pain. We can forget that growth and pain go hand in hand. Instead of seeing that pain as natural we turn away from it and turn away from growing. We spend years being the same person we were the year before.

That might be fine for you. I’m sure it is more comfortable and stable than a life where you never stop growing. But it isn’t for me. I’ll take the pain and the knowledge that I haven’t reached the top of my potential yet. I just have remind myself that this pain is natural on those tougher days.

OPE

Other People’s Expectations.

They are rarely reasonable. They don’t know what you have going on or your plans or who you are. They want you to fit in with what suits them and fits their needs. Due to our social nature they can easily creep into our heads and convince us they were always there. That they are ours.

Fight them with communication and self reflection. Sometimes you only need to reset them by expressing yourself. You can only know what is yours and what is theirs by thinking about who you are, what you believe, and what you want.

Building Confidence

Confidence doesn’t come naturally to me. When I was young I was shy and timid and nothing changed much as I grew up. I was different enough from the other kids in elementary school that I got made fun of and bullied. My lack of confidence probably reached a peak my junior year of high school when I didn’t say more than a few sentences to my peers the entire year.

Today I’m very confident. I strongly believe I can do anything I put my mind to doing. I believe I owe my confidence to taking on challenges that tested my faith in myself and overcoming them. What do I mean by “challenges that tested my faith in myself?” I’ll explain.

Despite my confidence today I still doubt myself. When I hit trouble on a project a voice in the back of my head starts calling me names. Stupid, incompetent, a fraud, in way over my head. That’s my fear talking and it is a great sign that I’m challenging myself the right amount.

That fear can be enough to break your will and make you stop and declare failure. But if you push through it to the end and declare victory then you’ll build your confidence. After a few experiences like that you’ll be unstoppable.

My key takeaway about building confidence is that it comes from putting yourself in situations where failure is possible. You can’t fool your fear with simple tasks that you can easily overcome. You have to forge your confidence in the fire of challenges that test your faith in yourself.

Silver Bullets - Cross Platform Development

My title for this blog post is on the technical side but I’m going to keep the discussion high level and non-technical.

Silver bullets kill monsters.

In software development we have a fairly large and insidious monster called Cross Platform Development. This monster shows up when you want an application to work for everyone, like when you want an app that works for both Android phones and iPhones. But despite that example, this monster wasn’t brought to life by the smartphone. Before smartphones, Cross Platform Development could mean Mac and Windows, Windows and Linux, or any such combination. This problem has been around for at least 30 years and software developers have been looking for solutions for nearly as long.

I’m firmly in the “anti-Silver Bullet” camp – I believe that software development is a complex task that cannot be simplified without losing something. By losing something, I mean that to simplify software development you have to compromise somewhere else, in performance, customization, control, or design. I don’t like compromise. I also believe that humans are much more flexible than computers and they should be the part of the system that bends to make things work rather than expecting the machine to do it.

I’ll talk through the benefits of the Cross Platform Development Silver Bullet because, despite my bias, I do see definite benefits.

The biggest benefit of the Cross Platform Development Silver Bullet is that you have a single code base rather than having a separate one for every platform. This is good because it takes time and money to write code, fix bugs, and test applications. Those costs are greatly reduced with a single code base and not just during initial creation of the application but for the years of maintenance that follow. This seems like a simple concept but it is a huge deal.

Another benefit is developers don’t need to learn as many languages. A single code base will probably be written in a single language and you might also need to speak the databases’ language (although the hip thing these days is to have the database speak the same language as the code base.) a single language means it is easier to find software developers that speak that language. If you want to write native (the opposite of Cross Platform) apps for every platform right now, you’d need to speak somewhere between 3 and 5 languages minimum.

In most evaluations this would be the point where I’d share the downsides of the Cross Platform Development Silver Bullet. But it has no downsides. The problem is that it doesn’t exist. In specific, it doesn’t exist for what I need software to do. I do think there are situations where a Cross Platform Development Silver Bullet could work – situations where the compromises are OK. Let me tell you why it won’t work for me.

First, it is too risky. These Silver Bullets are code bases themselves, software written by teams employed by large technology companies. These companies can afford to have very smart people working on open source projects because it makes sense for them at the time. But what if that changes? What if the company changes its priorities or goes out of business? The code you’ve written will become useless, not immediately but over a relatively short time of months or years. You’ll have to rebuild everything. You may be thinking “it is open source, someone else will pick it up!” Which may be true, but will they be as devoted to the project as the original team? Will they be as smart as that team? What are their incentives? Again, too risky.

Second, and this ties in with the first reason, you will only be able to use the tools that the developers of the Silver Bullet give to you. If a shiny new feature comes out and those developers decide not to implement it, or worse, give you just a little control over it but not full control, then you can’t use it the way you’d like to. You may be thinking “well that’s no different than if Apple hasn’t provided the feature” but you’re wrong. It is different because other apps can use the feature and users of your app will see that. If others can do it and you can’t then you’re at a disadvantage.

Third, you will always be a little bit behind the features that native developers will get. The Silver Bullet works because people write code to make it work on multiple platforms. If a new feature comes out you have to wait for those people to write the code to enable it. And what if one platform has a feature that another doesn’t? How does that work? I don’t know, but the Silver Bullet can only solve that in two ways, either making you write that code yourself or not including that feature on either platform (I suppose there is a third way which involves adding a note in bold to the documentation letting you know that it only works on one platform, but that’s not a great option.) Again, you’ll always be behind.

Fourth, your application won’t feel right. This is the mushiest point I’ll make, but we are a mushy species. Each platform has its own design style which is one of the ways that they differentiate themselves. Each platform is motivated and incentivized to keep their style unique. That design style goes further than the way things look, it is the way they function too. The way things look is easier for these Silver Bullets to get right. But the easiest way to make the functionality right across platforms is by limiting options. This means you can’t differentiate your app as much as you might like. It also means that all apps built with the Silver Bullet start looking the same.

Do I believe that every app should be native? No. I believe you need to use a different tool for different situations after weighing the benefits and drawbacks. I don’t believe there is a one size fits all solution.