Highly Supportable Garbage

Posted on by

During the course of developing Equals we have spent a lot of time thinking about what we are developing, developing test code, and then re-writing final code that ends up getting implemented in the project as appropriate. We also have a large backlog of previously written code to work from, although a lot of the prototypes are in Objective-C for iOS which we can’t use on the web. The good news is we have learned from all of our previous mistakes.

The benefit to all this throw-away code, something we have never really had before, is that the final code is a lot more solid. Rick and I are both noticing that we aren’t hacking in a lot of code to just make things work. That’s been a facet of almost every project we have done in the past ten years, which is partly a bi-product of having near-zero experience on the platform we are working on and always being in a ridiculous hurry.

With Equals that has been less of an issue. As we fix bugs now it is clear that the logic was correct. The changes are inserting a line here or correcting a mistake there, but not having to either rototill code or hack in fixes for stuff we have. It feels more stable.

This hasn’t just been because of the previous code we’d written, of course. Another big benefit is that we took far more time than ever before to plan and document what we were doing. An insane number of hours, for instance, went into figuring out how the server-client API should work. Even stuff like how do we determine what’s a variable and what’s an equation was hours of planning and thought. I had a college professor say that 70% of development should be planning. This is one of the first times in my career where I was near that number.

None of this is to say we won’t look back at this code in a year as garbage. But at least we know in a year that this code will be highly supportable garbage.

Marijuana and the NFL

Posted on by

I don’t write about sports very often so forgive my dalliance today. This is as much about society as it is about the NFL. There’s a football player named Josh Gordon who plays for the Cleveland Browns. Word leaked the end of last week that he had been busted for marijuana in his system and, due to his past history, may be kicked out of the NFL for an entire season.

I’ve been thinking about this all weekend and find the whole situation ridiculous. Why?

  • Marijuana is decriminalized at some level (decriminalized, medical use or unrestricted) in 26 states plus Washington, DC. This is more than half the country by number of states and far more than half the country by population. Gordon, who works in Ohio, is in a state where it has been decriminalized.
  • In the NFL the reality of head injuries means, likely, that any player could find a doctor who is willing to give him a medical marijuana waver.
  • Marijuana is fully legal in two states that have NFL teams, Colorado (Denver Broncos) and Washington (Seattle Seahawks).

We are talking about a bunch of very wealthy young men who have nothing but time on their hands right now. It would be no problem for any of them to hop on an airplane to a legal state, buy some weed and smoke it, then fly home. Weed stays in the system for weeks after ingesting it, far longer than cocaine and other drugs.

This whole thing jumps off the rails for me way too fast. Why is the NFL policing pot use but it never seems players are busted for steroids? It is impossible to believe that many NFL players are not juicing.

Why police marijuana to begin with? What the NFL should care about is one team getting a competitive advantage versus another. Can anyone credibly claim that smoking pot gives players an advantage? If anything it would seem to be the opposite.

Why does the NFL bust players for pot but the NBA and MLB don’t seem to. I can’t think of a case where a basketball or baseball player was busted for pot or any other drug that was not performance enhancing. (Update: I found out after writing this that the NFL does not test for the steroid HGH but does test for pot. That makes no sense at all.)

Why does the NFL think it should be a more important governing body than state and federal government? On last reading I didn’t see the NFL listed in the Constitution as having unalienable rights.

How is the NFL going to handle legality of pot usage in different states? If you play for Denver or Seattle players can smoke but in other states they can’t?

And why is this not being discussed among writers and others as an issue that major sports leagues, including the NFL, needs to deal with?

I know the counter-argument: the NFL has the right to do what it wishes with its own employees, just like any company can choose to drug test and fire employees who violate its policies. But there are at least three huge differences here: 1) the NFL is a monopoly. It’s not like these players have a choice to go play somewhere else that doesn’t have the policy. They can’t shop their skills to the highest bidder. This is more akin to the tech industry deciding for all participating companies that employees caught with pot in their systems will be banned; 2) he is not an employee of the Cleveland Browns nor the NFL. He is an entertainer hired on contract. And right now he is not required to perform; 3) companies fire employees for failed drug tests. The NFL isn’t firing him; it’s putting him on probation for a season.

The NFL (and all sports leagues) is going to have to come to terms with this and soon. For better or worse, it is clear that more states will legalize pot. (There’s too much tax revenue available by doing so.) It’s one thing for a team to punish a player who shows up high to practice or a game; it’s another to punish said player for doing what is legal. In the next few years, many states will start treating marijuana like alcohol. Wouldn’t it make more sense for the NFL to be out in front on this issue?

—

So you know the person behind the writing, I have mixed feelings about legalizing marijuana and have to admit that if I was czar of Oregon, I’d have the state wait a few years for Washington and Colorado to work out the kinks and discover the problems.

I also have concerns regarding the impact for our under-25 crowd. I’m concerned that that group will find it less of an issue to smoke if it is legal. Those effects , especially for those under 25, are not good.

Personally, I’ve never smoked pot although I have been around plenty of it in my lifetime. My decision to not smoke has nothing to do with its legality, although it might have when I was 16.

 

Regular Expressions May Be The Most Powerful Dev Tool I’ve Ever Learned

Posted on by

I started programming in 1986 when I got my first computer at age 13. It was an Apple IIc and the primary language on that machine was BASIC, so that’s what I learned. I exclusively programmed in BASIC until 1989 when my high school got Macintoshes and we spent the next two years working in Pascal.

When I graduated from high school I stopped programming for a few years. I started again in 1994, the year I moved to Oregon, and programmed steadily until 2001. In those years I learned C, a little assembly language, a little Microsoft’s foundation classes and finally Palm OS’ libraries. I also worked in BASIC for Excel and Access.

In 2001 my development team kicked me out of the dev room and told me to go focus on the business, which I did until the company shrunk again and I had to write code. That year was 2007. I learned Java and the Blackberry OS’ libraries, learned Ruby and Rails, and then got back into C development, this time with iOS’ libraries and Objective-C. I focused on Rails and iOS for the next few years before I started learning Javascript last summer. In the last year I’ve written more Javascript then Objective-C.

I left off one “language” that I’ve learned in the last year, probably the one I find most powerful and flexible: regular expressions. Regular expressions, or RegEx for short, is a way of finding and pattern matching text. It is unbelievably powerful and fairly easy to learn the basics. I thought I’d learn a little RegEx, use it a little bit, and never really need it again.

Not only does it turn out that Equals uses them constantly, I’ve also found other uses as well. For instance, my daughters’ school needed some content extracted from email messages. This task would have been impossible without regular expressions, and was so thankful I knew them before I started.

The book I learned with is Mastering Regular Expressions by Jeffrey Friedl. I also use a Mac app called Oyster, which allows me to write expressions, set up tests so I can verify that my changes work, and then copy my RegEx to the clipboard in one of 12 different languages that supports regular expressions.

If you write code or process text and haven’t spent any time learning RegEx, I highly recommend it.

 

The Equals Story: What’s Taking So Damned Long?

Posted on by

I’m experiencing a writing drought right now of proportions never experienced before. I love to write and yet the last month or so has been like pulling teeth to get anything down on paper, if you will. I realized that at least part of that is because I have always been reticent to dive into the weeds on what we are working on, mostly because I, for whatever reason, think it will scare all of you away.

Well, too bad. If you leave you leave because we are deep diving now, my friends! I’ve decided to write a series of posts on the thoughts and decisions behind Equals. I’ll make sure it is noted clearly in the title so you can ignore these if you prefer.

The concepts behind Equals came from an app my partner-in-code Rick Huebner invented in 1998 called MathPad. The concept was simple: what if the calculator was a piece of paper that you can write text, equations and variables on, then hit a compute button and it would fill in the missing values? It was a positive little seller but it had very small revenues compared to powerOne and we shelved it soon after Rick came to work for me in 2001.

It sat in holding for 10 years until it was brought up in 2011 in a multi-month exploration of new ideas. By 2011 we had already been selling apps in the iOS App Store for 2+ years and it was clear that selling productivity apps at $5 per copy was never going to make us enough money to even be in business, let alone support the two of us full-time. So we started hashing around for new ideas, still based on spreadsheets and calculators and numbers, that we could develop. We came up with a dozen ideas, built a few prototypes and started testing. Equals, which we were calling MathPoint at the time, was the most interesting and compelling of these partly because of its connection to our existing powerOne customers.

We spent months using MathPoint ourselves and with a few close friends of the company. We began to refine it. We eliminated all of the syntax complexity of Rick’s MathPad, we expanded variables to include numbers and spaces, which made them feel much more natural. We went from purely text-based notes to include formatting and started playing around with how to do that on iOS and the web. We even moved from an iOS-only app to a sync-based system to a web-first application. Refining and simplifying took forever. We came very close to releasing apps a few times but backed off for one reason or another each time.

Our momentum on the project was slow. Throughout we had two core problems: 1) we were moving more and more toward a web-based product as a starting point; and 2) powerOne was/is making so little money that it wouldn’t support even one of us full-time. So we took the value we had — iOS development experience and a well-regarded product — and sold those. We received a number of custom development contracts over the last couple of years, all of which kept us in business. Our income went from 100% product to 70% custom development work but we also had profits for the first time in years all while paying ourselves a break even salary.

As mentioned, though, our philosophy about where to release the first versions of Equals changed as well. We went from an iOS-only app to an iOS app that leveraged the web for syncing only to a browser-based app. I hope to get into this decision later but for now understand that at the time we made this decision we had very little experience with browser-based, HTML5 apps. We had worked with it a little in the iOS app, but very little.

So we got a development contract that basically paid us to learn HTML5. While the project was a huge pain, we were able to learn rudimentary skills and it brought us enough money to give us a window of development in the summer and fall of 2013.

We thought we were close. We reached out to some of our existing powerOne customers, getting them all excited, when we thought we were within a month of shipping. Unfortunately the window collapsed. One reason was because we had some health issues that our now dealt with. Another is because getting a releasable version turned out to be far more complex than we ever anticipated.

The window closed. By the fall of 2013, we were again running out of money. We closed more contract deals and focused exclusively on those. By early 2014, though, we had stockpiled enough money again to focus full-time on Equals. In fact, we have now stockpiled enough contracts and deals to likely need no contract work until the end of 2014, our longest window to focus exclusively on Equals (and get paid) in a very long time!

As we’ve been head’s down now for more than two months on developing a web-based version of Equals, we are finally getting very close. It has been interesting, though. Sometimes we think we are closer than we are and sometimes we are battling the technology for weeks on end trying to make it do what we want and sometimes we head down a path only to realize, after getting 95% of the way there, that it was absolutely the wrong technology or process.

It turns out the devil really is in the details. The amount of spec writing I’ve done in the past few months far exceeds the design work I’ve done in the history of the company, and of course every time we make a change it has ripple effects through the code. Add to that our relative inexperience with HTML5 and our time estimates have been way off.

Anyway, that’s enough for now. All I can say for certain is we are (finally!) very close. Yesterday I pushed to the live server our first partially working version and hopefully the remaining handful of missing pieces will lay in quickly over the next few weeks. The learning hurdles should be behind us now as we have the basics of the technology working. We need to finish up the last missing pieces and test and test and test.

Our goal is to roll this out slowly. We have never had to worry about server load before and we have never had to worry about client-server interactions and all the unknown unknowns that go with new technology on a new platform in a new environment. I’m also worried about the rudimentary nature of Equals. It is so early and there is so much to do. I hope Equals isn’t too far down on the minimum viable product curve.

I can’t wait to share it with you, though. It has been a slow train coming.

—

Would you like to know when Equals is ready? Tell us. Your email address stays between you and me.

 

Managing Risk

Posted on by

I’ve spent a massive amount of my time while running Infinity Softworks managing risk. In this case I’m talking about business and technical risk. When do I count revenues? How reliant am I on a partner? How reliant am I on a technology sticking around?

Sometimes I’ve been good at this. I’m conservative about deals, for instance, never adding cash expectations to my budget until the contracts are signed. Sometimes I’ve been bad at this. We were extremely reliant on Palm in 2004 and didn’t even understand how reliant we were. When the relationship failed 70% of our revenue disappeared at the same time.

Yesterday App.net announced that renewals didn’t meet expectations and that the product would continue but that the team developing it would no longer be full-time. Development would be open sourced.

This doesn’t bode well for those that rely on ADN for log in and syncing services, the developer back-ends. If I did, I would be looking for an alternative right now. In managing a business it seems that I am always surrounded by risk. My goal is to minimize it as much as possible where possible.

This is one of the reasons we don’t do log ins with Facebook or Twitter or Google. This is one of the reasons we prefer to manage our own servers. This is one of the reasons we have multiple revenue sources. As I was planning Equals one of the things I thought about was all of these risks. It is one of the reasons we chose to develop the web version first and mobile-specific versions later. Relying on Apple, Google, Samsung and Amazon to provide us customers is dangerous, especially if we factor in the rules that go along with participating in someone else’s store.

Honestly, it isn’t possible to get rid of all risk. But it is important to consider which risks are worth taking and eliminate all the rest.