The Codisthttp://thecodist.com
en-USSat, 10 Dec 2016 02:59:39 +0000Mon, 21 Nov 2016 21:27:41 +0000The Story of My First Startup 30 Years Agohttp://thecodist.com/article/the-story-of-my-first-startup-30-years-ago
This is a story of my first startup from 1985-1988; some of this will seem so familiar to people who have started companies today and some will seem completely alien as the world was much different back then. People haven’t changed much but technology, knowledge, the market and opportunities have. Failure is still the most common result even today.

Some of this I have never told anyone in detail before but it’s been so long now it hardly matters. In the end it’s a story of a great idea wrecked by poor decisions and the world’s worst marketing idea—competing with Microsoft head on.

It’s ultimately my idea and my fault, though I leave it to you to laugh, groan or nod in understanding.

I started my career at a defense contractor in 1981. By 1984 I had wormed my way into the “Microcomputer” group, basically at the start of the PC era, but eyeing the brand new Mac I saw the future and wanted to be part of it. So I shocked my manager and quit.

Of course I had no real idea what to do yet. I worked with a friend of mine on a suite of spreadsheet templates for the oil & gas industry which seemed like a good idea until we discovered they didn’t really use computers yet! It was slow going and not much fun. I noticed one irritating fact about spreadsheets: it was easy to make errors and proving the calculations were correct was painful.

Now in 1984 Microsoft’s spreadsheet program was Multiplan—you thought I would say Excel but they were still working on it. One day I was frustrated with errors in my Multiplan version and started wondering if there was a better way to build a spreadsheet.

I still remember the flash of inspiration that building calculations on groups of related values, which we later called blocks, based only by names might make errors unlikely as such an application could keep things correct for you while you focused on the relationships and not the mechanics. I ran over to my partner and we talked with the other folks in the shared office suite to see how we could make something out of this radical idea.

One of the folks ran some kind of consulting company, was a lot older and said he knew a lot of people who might be willing to invest in something. You have to realize this was 1985 and for most people software was a strange concept, and the idea of investing in building software was like asking for investment in a trip to Mars. Of course today these folks would be called angel investors but I had basically no idea of how to proceed or what this meant.

This older guy seemed to know a lot of stuff and that was my first mistake, I didn’t really know much about him or his business and didn’t want to ask. What I didn’t understand was his business was consulting at failing businesses for stock, running it into the ground, picking up the remaining pieces for pennies and then selling it piecemeal for profit. Some of his buddies would also turn out to be less than supportive and more than willing to take advantage of the naive me.

First I had to create some presentations (not in software, that product didn’t appear until later) and try to convince people who didn’t really use computers, much less a Macintosh, that there was a market and we could make money with a fancy calculation application. Also remember there was no Google, no online anything to help. I bet I told a lot of random bullshit. Of course no one knew that!

Anyway we got a reasonable amount of investment. For some reason we hired a young lawyer fulltime to write all the contracts (he had never used a word processor before). The older guy agreed to be the CEO (for stock) and me as President, and a board of the CEO and another buddy and me. He also helpfully agreed to handle the checkbook. Oh man that was bad idea number two.

So now I needed to build a team; thankfully I knew two great programmers, one from my first job and one from my college days. Both thought it would be cool to work on something amazing and we started in summer of 1985 to figure out how the heck this crazy idea might work.

We figured out how a spreadsheet like program could work with named blocks, how the calculations would work, what happens when you resized things, how it might look, all the stuff you might do today—the big difference was there was nothing to go on, unlike today everything we wanted to do we would have to do ourselves. We decided early to write in C even though the Mac was mostly Pascal at that point. C seemed to be the future.

Our development was, compared to today, not much better than stone knives and bear skins: two Mac 128K and one Mac XL (a Lisa rebuilt as a Mac) with a single hard drive which the other two shared over Appletalk. We had a C environment with the world’s slowest linker ever. We had a copy of Inside Macintosh, K&R C and a 68000 assembly manual. That was it. We did eventually get one “open source” piece of software: a ripped off copy of the Unix Lex & Yacc which had to be ported to the Mac first. Oh I also had bought a GUI library called MacExpress which would help in making a UI happen, something of course none of us had any clue about.

That was it. Everything else we thought of ourselves. It was crazy primitive. Ken worked on the spreadsheet engine, Bob wrote all the functions and the formula parser, and I did the UI. We were working on 8Mhz processors with a 5MB hard drive and floppies and tiny screens. No repository (none were available), a low level debugger (MacsBug) and patience!

By August of 1986 we were making good progress on the app so I went to the first Apple WWDC (not called that back then) at the Fairmont hotel in San Francisco, with most of the world’s Mac developers fitting in one room. It was humbling, so many amazing people. In August we all went to the Boston MacWorld so we could see what other people were building.

I have never been so shocked in my life—I realized that my year of writing and designing our UI was awful. Realize back then that knowing what other people were building was hard, you basically had to buy software to check it out, other than minimal photos in magazines. It was hard to know what the industry was doing, and I had not realized how dreadful our UI was. To this day I don’t remember what it looked like, but I was almost despondent about it.

So when we got back I decided I would continue to support the existing UI (so Bob and Ken could continue working) and write an entire new UI from scratch, and get it done in the four months before the San Francisco MacWorld where we wanted to ship it. I worked 100 hour weeks for the next four months. It was insane. One key thing saved me; when I was at the show I saw a little university demo for something they called a hierarchical menu, which popped up when you tapped a mouse and added menus to the side as you moved to the right. It was perfect for what I decided to do and became the central UI feature. Apple did not ship popup and hierarchical menus in MacOS until some time after we shipped.

So in the midst of this insane working we had to come up with a name. We tossed a bunch of lame ideas around and one investor had listened to the radio and heard a band called Trapeze. Boom, it stuck. It made little sense but it was cool.

Now of course we knew that the leading spreadsheet program on the Mac (Windows of course wasn’t really a viable thing yet) was now Excel. Now I made the really dumbest decision ever, I knew nothing about marketing, and there was no one to ask unlike today, and selling retail software in those days was strictly in stores though distributors and via mail order stores. So I thought we should sell the product that way and go up against Excel. Even though Microsoft wasn’t as dominant back then as in the 90s and later, it was still the big dog. Trapeze itself was not really a spreadsheet program, you could think of it as a numerical modeling application halfway between Excel and Mathematica’s numeric side (though that product didn’t exist yet). But stupid me thought that because Trapeze was superior in many ways, we would compete easily, and the market would support us both. Gag, what a moron I was. But selling software for most companies was still a new idea, a few years earlier people sold software in baggies! Today that sounds so Neanderthal but everything starts at the bottom.

So we had to write a manual, start thinking about disk duplication, printing, boxing, shrink wrapping, making deals with distributors and mail order, building a show booth; and all of this while I was working 100 hours a week trying to rebuild the whole UI. What we didn’t pay attention to was money, stock and “deals”. Every time we had a board meeting the majority would vote themselves some more stock and the three of us writing the code had less. Payment s were made on the bank loan that I realized later were kickbacks; the advertising agency seem to be paid much more than they charged, and the like. Things like this slipped by me. Trying to do all of this was really ridiculous.

We placed a teaser ad in Macworld. Talking with various press people they all thought we were Ashton-Tate, one of the big companies at the time, teasing a new product. Of course you had to place ads months ahead, unlike websites today magazines had long lead times. But back then ads and reviews and shows were the only way anyone would even know you existed, especially the stores as the distributors did nothing for their 30-40% but deliver boxes. It was up to the publishers like us to drive demand or the distributors would ignore you.

Somehow we got to the day before leaving for San Francisco (we were in Texas), the last night was an all-nighter as we wanted to have some manually produced copies to sell at the show. Someone plugged in the coffee maker and the toaster at the same time, blew out the circuits, and I lost two hours of code! Thankfully we got done in time to fly out.

At the show we had a lot of press and people were impressed by what Trapeze could do, seeing a spreadsheet like program with built in charts, drawing, text and the ability to build complex calculations quickly and the popup/hierarchical menu was a real stunner as no one had seen this before. Of course there was a stupid show bug, 1/6 of the time I clicked on the menu it would crash. We had always run the app with the debugger present; at the show we had rental Macs and no debugger, and the change in memory location was enough to trigger a dangling pointer value that would randomly crash. Really embarrassing when you are giving a demo to 50 people!

The show was otherwise a success and we got a lot of distributor orders and it seemed things were going positive. What we found was the many people tried it but had no clue how to use it effectively as it was so different than a regular spreadsheet. A lot of people complained they couldn’t import from Excel. Explaining that was impossible (even assuming we could read the format which wasn’t open) didn’t help much. The cool thing was that some people immediately realized how powerful Trapeze could be, they understood the concept was quite different and allowed you to do things impossible in Excel (and sometimes vice versa). So there seemed to be enough of the latter to offset the former.

Then we got the first review, in MacUser magazine.

A year later Bob and I met the author of that review, and he apologized that on the day he wrote our review, he had had a personal problem which caused him to be extremely angry, and he took it out on us. He ravaged Trapeze, basically made it seem like a complete waste of time with no value at all. A positive review in MacWorld followed shortly by then orders dried up; the damage was done. In those days a single review might kill your business as there was basically no other way for people to know if something was worth buying.

We took all the criticisms and worked hard on a major update but we could not overcome the inability to import Excel. The people who really understood Trapeze were big supporters anyway, we had people doing amazing things with it, generally using it as a data modeling application for verticals like business, science and engineering. But we were still selling it retail against Excel like dummies.

By summer it was obvious we would not survive much longer as money ran low. Now things got ugly.

By the summer the three of us programmers found ourselves with only 5% of the company; we had been diluted by the board members to the point we had little left. Now we had signed a two year employment contract back in 1985 which was expiring. The board members including the CEO, who now owned the bulk of the stock, insisted we should work for nothing for a further two years to “save” the company. We said no, we had worked for a low wage during that contract and working for nothing simply wasn’t affordable; plus our stock percentage was so low it didn’t make sense anyway as there was nothing we could do to improve sales. After all the hard work it just wasn’t enough but they refused to accept paying us anything and we then resigned, walking away with nothing.

Now they were stuck with the worthless stock and an application they couldn’t find anyone to work on. For some inexplicable reason they convinced some poor dentist to invest his bedridden mother’s nest egg into the company despite knowing it was a dead end. Later on the dentist sued the company and got some of it back. We had no idea since we were long gone.

At least at that point they decided to simply sell Trapeze to a company called Access Technologies which had some other Mac products they had bought.

I started a new company with most of the tech folks that would support Trapeze for its new owners. Later on that company split and became Deltapoint. That would prove a great move and the two of us built Deltagraph by 1989. The last version of Trapeze was compiled in 1989 and then was discontinued. It lived only 3 years.

The last part of the saga was the most ugly and the part I have never mentioned before. The CEO decided to punish the three programmers financially with what had to be the most hairbrained (and illegal) tax scheme I’ve ever seen. Because he hadn’t informed the investors of what transpired, he had to give them something or they might have sued him. So he and a tax lawyer concocted a scheme to give R&D tax credits (or something like that, my memory is hazy) to the investors, and charge all the cost of these credits to the three programmers. Yeah, it made no sense back then either. We talked with the lawyer and he was pretty vague on the reason (I do remember him saying something about foment in Congress!) and it was pretty scary as our tax bill was $100,000 for each of us. Thankfully our accountant was pretty smart, and he said just explain it to the IRS, and basically ignore it, as it was complete nonsense, which worked! I have to this day no idea what happened to the credits on the other side. I never saw any of the board again that I remember.

So that was the end of this adventure that started with a good idea and ended in a strange tax land. What did I do wrong? I didn’t realize how stupid it was to compete with an established market leader with a product that was not really a competitor. Trapeze really fit in a place different than a spreadsheet like Excel. It could do things Excel still cannot do today, it was faster (since it could calculate things in tight loops) and allowed you to integrate charts and text (things Excel didn’t get until much later) and even do some presentation (since blocks could be moved around, resized, formatted, all without affecting the calculations). It also could not do things Excel could do since it didn’t support cell by cell formulas; this was a feature we had thought of as a sort of spreadsheet block but could never implement. Trapeze was really something that should have been sold to Universities and research companies and the like directly, basically like what Mathematica was targeted at. That was a lesson we didn’t learn in time. Once people understood the how Trapeze worked they often became enthusiastic users. I still get emails (and tweets) from people who still remember it fondly from so long ago.

Today it would still be a useful app, since it would have been a natural atop a relational database or data cube, and maybe utilize the GPU for calculations and even import Excel into a block! I still will never forget how cool it was to see something no one else had ever thought of and bring it to market, and despite all the ultimate pain, I am glad I had the chance. All three of us still remember the joys and sorrows of that little period when software was new and came in boxes and people read about it in magazines.

One more favorite memory of back then: going to a banker telling them we were a software company and having them think we were building ladies undergarments!

]]>Mon, 21 Nov 2016 21:27:41 +0000http://thecodist.com/article/the-story-of-my-first-startup-30-years-agoI Miss Being Part Of A Complete Teamhttp://thecodist.com/article/i-miss-being-part-of-a-complete-team
I work for Ginormous Corp, Massive Division, as part of a high profile project, doing the part of it everyone is watching. Yet we are dependent on a dozen teams, spread out over the whole division, with an insane amount of dependencies, meetings, processes, systems and modules. Constant changes coming from all over the place make even knowing what we have to do and when a continued struggle. We have to worry about distributing budget, getting and making estimates, try to negotiate with other teams for their part, and somehow make progress with our part.

It’s beyond frustrating and is clearly a big company problem. This project has visibility to the parent CEO and a lot of investment. I often say we are the little penguins on top of the giant iceberg: everyone sees us but no one seems to notice the massive berg below.

I really miss being part of a small wholistic team, where everything and everyone we need is right there or at least fully involved if remote. A lot of times in my 35 years that was the situation including my two companies (85-94) and other occasions including two jobs ago at the travel company (now sadly just a brand of HugeTravelInc).

Being a part of a team all working together on one or more products, with a product manager, designer, QA, developers and maybe a few other folks all together is to me the perfect environment. At the travel company mobile team we had about 20 people including all of those roles and just a single manager. The CEO left us alone (with 2% of the companies employees we did 15% of the revenue) other than one time to build him a special app. We had 4 apps for iOS, one for Android, mobile web and also a mobile API in front of the monolith backend. We shipped frequently, even daily sometimes, we all traded off different products, participated in product decisions, design decisions, iterated on ideas and even interacted with actual customers to see what else we could do. We had fun together and did virtually no overtime at all.

Of course my two little companies were the same, the first that shipped Trapeze it was 13 people, and the second was just 5 that worked on Persuasion (for the author) and Deltagraph for 5 years (for the publisher) and was similar. It was rewarding to work on something where you had input into everything from UI to functionality to experiments in wild new features. We also had full-time QA people who knew the products backwards and forwards and made shipping a breeze (which it had to be in those days we shipped on floppies with no chance for patches). Even back then we rarely had to work extra time since we shipped when it was deemed ready and not on some random number schedule.

Today the pressures and stress is insane, mostly because there are so many people doing so many things that all have to be coordinated and contented and cajoled and sometimes forced to do things. Design, product, process, schedules, estimates, and change requests are a constant swirl of confusion. We call it agile but it is just waterfall with agile floaties, barely keeping above water. It’s frustrating and the developers have almost no say in anything other than these random guess estimates based on often vague stories which become cast in unobtainium and scheduled to the day.

I miss being involved in all the roles; I’ve been the head person as well as just a team member, but in these great places I was always able to suggest improvements, try new things and have everyone bounce ideas around to make stuff better. To me that’s the beauty of having an involved, excited team building stuff we all care about.

While some of us here are passionate about doing great work, the other teams are often random collections of contractors, often in various countries, who really have no understanding or interest in what we are doing or what our customers care about, and are just mechanical in working and making sure the billings continue. I don’t enjoy just writing code to spec on a time clock and fixed budget decided by others. I want to help but we have such strict hierarchies and silos that not only can you as a developer not suggest anything, but you may not even know who to suggest it to, if you could.

I was recruited into this position but the actual process was changing a lot and no one really knew how this big project would be done, so I had no idea what a giant mess it would be. The team I am on directly is very talented but we all suffer under the same strains.

The worst thing is not even knowing if this iceberg won’t crack underneath all this complexity and fail miserably. When you are the penguins people point to you so it’s hard to avoid the stares, even if the berg cracks underneath you and the sharks eat you up (OK enough with the cold metaphors!).

I like to ship. I like to ship apps that work. I like to ship apps that work and ship them in a reasonable time to customers who like them. There is nothing better than to talk with customers who love what you produce. My first product, Trapeze, still nets me emails occasionally from people who still remember how much they liked it, even though it was last sold in 1989!

Good products usual come from good teams that worked well together, and created it by functioning as a whole team and not just a collection of silos. I know a major airline still waiting on a new version of their app (now almost 2 years in the making) built by an offshore team that built their existing app which has always had miserable ratings. They thought saving money was more important than having a team of people who cared. To me thats stupid.

Then again building a product with 40 times the actual people needed, in great complexity and with enormous process and overhead isn’t very bright either. The eventual app will be built out of a myriad of pieces but is still not remotely as complex as an app we built at the travel company (flight, hotel and car booking) with only 3 programmers, one designer, one product person and 1.5 QA. Even Deltagraph (88-94) was built with only a handful of people and was a market leading product during that time (and for some bizarre reason is still sold in 2016). I can still see decisions I got to make in the product today (which hasn’t changed much in 20 years). I still remember why those things were done and how we all figured it out.

It’s the little teams that build great products that you remember, that you want to repeat over and over; the horrible monsters you suffered through you want to forget. Like the project I did in Mexico with 40 people crammed into a room doing a death march for 3 months. I did learn enough Spanish to order a lot of cervezas.

If you find a great team stick around if you can, it's worth it to be a fully involved team member and not just a warm chair which I imagine is what most of us get up to go to in the morning.

I am not just a cow: feed me requirements and I poop out code. I want to help conceive, build and ship great products with a fun team that doesn’t work too much. Is that too much to ask for?

]]>Wed, 09 Nov 2016 20:50:13 +0000http://thecodist.com/article/i-miss-being-part-of-a-complete-teamThe Unreasonableness Of Hacking A Presidential Electionhttp://thecodist.com/article/the-unreasonableness-of-hacking-a-presidential-election
I am really tired of explaining to some friends on Facebook how completely unlikely it is that Democrats are hacking voting machines to flip Republican ballots in Texas. I don’t understand why educated people believe rumors to be fact and refuse to consider how impossible this is to do.

It isn’t that I think voting devices can’t be altered individually in a controlled environment, but I cannot imagine how thousands of devices not connected to the internet can be hacked without anyone noticing anything. At work we can often barely update server applications or databases or even configuration files without major issues (which is sad). How would you even begin to approach updating a myriad of different electronic voting machines in thousands of precincts one at a time without anyone noticing?

Furthermore imagine how difficult it would be to rewrite the programming of a large set of different software and hardware versions you may not even be able to identify before arriving on site, having ready made software replacements that correctly function to flip certain votes and do it in a statistically valid way (flipping 100% of all votes is a dead giveaway). Since you have to install your patches one device at a time across entire states it would take a large army of people, who somehow have to explain what they are doing and why to a massive number of precinct workers without even one slip-up; a single guilty party would be enough to destroy the scheme.

For example in Texas each county runs its own elections and generally there is a clear set of policies for how machines are calibrated, how votes are collected (I imagine its usually a hard drive), how technicians are identified, what processes should be followed for each election. There are 250 counties in Texas, each handling elections differently but following standards laid out by the state. I don’t know how many voting precincts in total in the state but for example Dallas has nearly 800, each with a number of devices (electronic and paper).

Now imagine you wanted to hack an election, hacking each individual machine one at a time by 1000’s of individuals none of whom can get caught in full view of all the other precinct workers and the various levels of judges and officers seems pretty much impossible unless you believe in invisibility cloaks or elves. Just having enough time in a short election season to get this done and have it be completely successful without any obvious problems is impossible.

We can’t even release single apps that perfect without a single flaw. How would hundreds or even thousands of patches, each for a different ballot content and for different machines with who knows how many versions possibly work?

If for example we had a single national piece of software for voting machines, installed from an insecure network by non-technical people the day of an election without any oversight or validation: then I would believe it is not only possible but likely. No such thing exists at least in the US.

What would stop each party from attempting the same kind of hackery? Now you are not only patching myriads of voting machine software versions but dealing with other people’s previously installed hacks, leaving the poor machine likely comatose, which would be pretty easy to spot as well. This is software after all, a highly malleable but generally unstable mess if not carefully constructed and managed. Random people dropping random code all over the country with no one noticing is something that would only exist in a terrible fantasy movie.

Any programmer should laugh at this craziness since we have enough trouble getting the apps and systems we work with every day, after much process and testing and validation, to update and run correctly. Look at how many companies can’t even secure simple systems, and now somehow there are people who can hack thousands of separate systems simultaneously with perfect results and no one notices?

If you wanted to influence an election, it would be far easier to create random Facebook rumors and make a mess of people’s opinions, and perhaps dissuade people from voting; this is much easier to do than a grand conspiracy a hollywood hack script would reject.

As a programmer being asked to build hundreds of patch scripts for unknown software that must work perfectly each time and be installable quickly without suspicion and produce exactly the correct result but not too obvious would make me take an early vacation and not come back!

Just as a note I do not like any of the US Presidential candidates and find political parties of any kind anachronisms.

Over the years I’ve worked on and shipped a lot of apps, and delivered app like projects. Although every industry and type of app may be different, some things stick out as being important, or at least worth considering.

These lessons may seem simplistic but I’ve noticed that the more projects do these the more likely things will work out well.

Be liberal at the start of the project and conservative towards the end.

The time to take risks is at the start of a development cycle, assuming it’s reasonably long. That’s the time to try new tools or frameworks or languages. The closer you get to the end the less you should consider something new. Sometimes you have no choice, like when I had to ship an app on iOS 7 launch day, but unless there is an unavoidable reason, don’t do it.

The fewer the people—not just programmers—involved the more likely you will succeed.

Big teams need way more processes, planning and time. The difficulties of disseminating information, knowing what is happening, and understanding state is hard to overcome even with massive effort if there are too many people involved. It’s always better to work with a small team that can communicate directly with each other. I’ve done very large projects with only handful of team members.

Big companies (like my present employer) generally fail at this, as company politics and empire building force too much specialization to have small cross functional teams.

Small teams—when given flexibility in how they work and make decisions—can get more work done with less waste. Handicap them with too much control and process and you lose all the benefits.

More flexible processes always beat more rigid processes.

Agile means flexible. Agile with rigid unmoving processes, detailed planning of every task, and central control is never really agile, though people still call it that. It doesn’t have to be chaotic, but it needs to be able to change directions, make changes and try something else without endless meetings and detailed agendas. Building software is never easy—why make it harder than it needs to be by process getting in the way of progress.

Obviously if the team is very large you may not be able to be so flexible, but that’s rule #2.

No one likes meetings or status reports. If your team is small enough you can avoid it all by having direct communication. If you are co-resident get used to talking a lot, or use a tool like Slack or whatever you like. It can be annoying to talk with people all day long, but it is actually more productive as you can ask and get an answer right away instead of waiting for some future meeting where the agenda may not even get to your question.

Back 30 years ago we didn’t have tools of any kind but my team was in the same space so we talked all the time and made adjustments and plans as we went along. It might be hard to get used to but it helps optimize the work.

QA/testing should always begin and continue from the start with development, and the whole app should always be tested not just the new things.

If there is anything I believe in it is this. I learned early on 30 years ago that having quality testers who worked with the development team from the first day anything functioned is an enormous benefit. Over time they understand the product better than any of the programmers do, they find all the dark corners, and can even help find UI/UX that is irritating. Building Deltagraph from 1988-1994 (5 major releases) we had a full time tester who tested it all day every day. We had to ship on floppies with no chance of any patch disk and we never needed any.

Compared to this knowledgeable testing, throw-it-over-the-wall testing (like we have at my present employer) is terrible. Generally the testers don’t know much about your app, rely on potentially spotty documentation, communicate very little other than with “tickets” and you have no time to fix anything.

Quality is always best measured at the customer but you want any problems found as soon as they happen, not by them.

Features and deadlines should be mutually dependent on each other; i.e. you can’t get everything you want all the time.

Another terrible practice at many big companies: everyone wants everything always. You cannot constantly add features and leave the deadline fixed. If you want a hard deadline you have to be willing to cut; if you want all the features you have to be willing to wait. I find it amazing when I see people insist that you can do both.

I think of this as a clown car: sure you can keep stuffing clowns inside but eventually it will explode and shower you with clown parts. Likewise if you keep insisting on adding to an app but keep the schedule the same, you will get terrible quality and potentially angry customers.

Sadly I am watching this right now.

People who care about your product and company are always more productive than external contractors only motivated by money.

You should always try to have people who care about your company and your customers work on your software. If it touches the customer it should be owned by you. Contractors can be OK if they are motivated individuals, but hiring bodyshops to fill in your team, or even worse use a company who provides random people you never meet, all you get is unproductive people who simply rack up the hours.

I know of a major airline where their iOS app is horrible and has thousands of 1 star reviews, and it was built by such a company. They decided to hire the same people to build a new app and when I talked with them they were mystified why so little progress was being made despite the deadline being only a few months away. That was 14 months ago and still I don’t see it shipping. At one time that had a real team but decided to “save” money by outsourcing and eliminating all knowledge in house.

It’s not that you can’t hire terrible people or manage them terribly or make many of these errors and still get nothing good, but finding people who care and letting them be productive is far more likely to result in a good product. In the end it probably costs far less too!

Honesty is better than wishful thinking.

Generally I always want to tell people what is going on, what is the status, where are the problems, what we could do. In many companies this is not popular, you want to hide any issues or ensure others are blamed. Often upper management people are treated like demi-gods, not to be bothered with problems, freeing them to look at the “big picture”. Of course what happens is that when things go bad blame flies in all directions. It’s not that all leaders are interested in what is really going on either or have the slightest idea what to do. Relationships between those who lead and those who build have to be built on mutual honesty and respect otherwise you wind up with blame explosions and not successful projects.

I never said this was easy!

In small teams this is much easier but when you are part of a large organization it might be impossible. When Alan Mulally took over Ford a decade ago in his first meeting with his executive team he asked for status and no one said anything bad. Of course they were going out of business and it made no sense, but they had been trained to hide issues previously. Once he let them know it was OK the problems poured out, and he was able to find ways to fix things and keep Ford from needing a bailout. It’s hard sometimes to get this to work, but in the end you can’t fix what you don’t know, and you if don’t care to know it will probably bite you eventually.

Prefer flexibility over hard estimates.

Estimates are always wrong. Assuming estimates are always correct and making hard plans based on them is even worse. In the history of programming (which I have now been involved for about 50% of that history!) I doubt anyone ever got an estimate of anything reasonable complex correct. Even estimates in a Scrum iteration are rarely all the correct—multiply that by a dozen teams with mutual interactions, continuous change requests and external technology changes and your estimate is basically a random number. People are constantly being asked to work 100 hours weeks to meet a random deadline. It doesn’t work and it alway turns out terrible.

Software takes time and often you don’t know how hard it is or what the correct way to do it is until you’ve done it or at least get far into it. Making estimates based on some written “requirements” is at best an educated guess, and more commonly a random value. Now take 100 of those and add them up to generate a deadline and all you did is a glorified dice roll.

Scrum is supposed to deal with this but often it becomes a tool for management information and less about an agile process. I’ve always preferred a lean approach, even back 30 years when Agile wasn’t a term (or Waterfall for that matter). Flexible adaptation to what the progress is telling you, adjusting the schedule or functionality based on what is more important, and a willingness to change when it is necessary usually results in a good product instead of a hurried mess and burned out team. The Most agile Project I Ever Did is one of my favorite projects and a good example of being flexible.

If you are having fun building—and shipping— an app, you must be doing something right!

Programming is hard work, but if you really enjoy the project, your team members and care about your customers, then it will likely be reflected in the quality of the product. The best products and teams I am been privileged to lead or be a part of have always had a good time doing it. If everything is a pain and you are working 7 days a week and all you do is attend terrible meetings and you hate to go to work in the morning, then it might be telling you something.

Of course your mileage may vary! Possibly some of these points don’t apply to you, or you have found a way to get things done anyway. In every industry, type of app, or other situation you may not be able to do all of these things. In my 30 years of shipping apps to customers it has not always been ideal either, but these things appeared important in the successes, and the failures seemed to be missing some or all.

]]>Mon, 03 Oct 2016 22:16:58 +0000http://thecodist.com/article/lessons-learned-shipping-appsI Dream Of Somethinghttp://thecodist.com/article/i-dream-of-something
The project I have been on all year is doomed to failure, not because it can’t be done, but because there is a never ending set of additions and changes, while the completion date is moving earlier and earlier, with dependencies on a dozen other teams, multiple simultaneous app and server releases, and a decided lack of people. All with a budget with more zeros than I have ever seen in my 3.5 decades of doing this yet strangely that’s not a big help at all. Most of the budget isn’t even software.

One can attempt the improbable, tempt the impossible, but this is something beyond my understanding.

So pardon me if I avoid working this evening and dream of the things I would really like to do instead. Of course most of this is as unlikely as we are to finish this nightmare anytime soon, but stay with me here.

Be in charge of fixing Apple’s Xcode IDE. Oh man do I get frustrated with Xcode. I’ve been using it (or whatever it was called back then) since its NeXT days. Sure it's usable and I live in it every day, but there are so many painful things, large and small, many of which could be improved with just a little effort, even if the big stuff gets ignored. Why can I not reformat Swift? Or refactor? Why do I keep getting a big fat ? when I want documentation? Why can it not show me all the usages of a symbol? Why are plugins so mostly broken? Why do all the programmers at Apple not rise up in anger? Maybe they have no budget, maybe Tim Cook doesn’t care, I don’t know why, I just want to fix it. I’m sure I’ll never get the chance.

Create a new modern traffic light system. Just today I sat at a stupid left turn signal that ignored us for 4 cycles. Why are traffic lights so pathetic? With machine vision and AI being so advanced now why can’t we leverage them with cameras and maybe a mesh network with other lights in the area to optimize traffic flow. I am sure there is math that will do this. Of course you would have to use existing (mostly) analog technology so cities would be willing to pay for a minimal upgrade. You would also have to be careful with security to ensure it can’t be gamed. Maybe with driverless cars it won’t matter much. But it would be fun, and I could save time going to work.

Instead of creating a fake galaxy, use procedural generation to create what I like to dream is a Park Planet. It's a complete world (just one) all as a giant park with all sorts of habitats and environments. The whole point is everyone can do any kind of outdoor activity virtually, such as swim, scuba, hike, climb mountains, fish, hunt, hang glide, explore or whatever is fun to do outdoors, all without being able to damage anything or die. It has no point but to be in nature, hear cool sounds, pet deer, fall off of cliffs or whatever. You could see other people and interact if you wanted to do, or turn them off and have the world to yourself. Right now, I really could use a few minutes of hiking after another stupid meeting.

Build life simulators. I’ve always been fascinated by artificial life simulations, genetic algorithms and emergent behavior, if I had worked on a PhD in CS that would have been my research topic. I would love to build a plant simulator, a bacteria simulator, or some other kind of life simulator that created delightfully alive things. It would be fun to build one that created a virtual world the size of all the people running the simulation; your little corner would be connected to everyone else, so you never knew what might come visit or where your creations wound up. It’s so much more fun to create life than to waste it in meetings.

I would love to build a cool application and get to both code and organize the project and product, the team, the testing and ship it without 800 other teams telling me what to do and how to do it. I shipped my first app in January 30 years ago, and I got to do all of that. I’ve performed all the usual roles together a number of times; its much more productive and a heck of a lot of fun. But today everyone wants to specialize and especially in ginormous companies like my current employer, every role is owned by a huge organizational silo. I miss being able to make cool stuff with fun people in a manner that always worked in the past and still worked a couple jobs ago at the travel company mobile team. I want to come to work and get excited.

Work on something so new and so unknown that a search in stackoverflow comes up empty and Google has no answers. Back in the 80’s almost everything you did was new, and working on something where no one could help you was fun. Today everything has been done by someone somewhere and they probably wrote a massive blog post about it and raised a billion in VC money to exploit it. It’s hard to find a coding-without-a-net idea anymore. Programming today is more following orders in some technology you wouldn’t ever pick based on a design someone you don’t know drew in Photoshop and planned by some pie in the sky VP. Building Photoshop for the first time; now that would have been fun. I did that sort of thing back then.

Going away on an around the world cruise. Hey, not everything is software related. The world is a interesting place; sadly I sit in front of a Mac and type instead. I’d probably still do some of that but the scenery would be much nicer!

Volunteer in some poor country building something for people who really need it. The best projects I did working as a consultant was when I made individual regular people’s jobs better or easier; the thanks and smiles you get improving someone’s life is worth all the effort you put into it. Sure the thing I am working on will eventually make our customers happy but will global warming or crazy politicians destroy the planet first? Hard to say. My bet is on the politicians.

Write a new blog about the future, science and technology and the human condition. I’ve always been fascinated thinking about where we go from here (assuming we survive) and where today becomes tomorrow and leaves yesterday in the dust. Thinking for a living would be fun with fewer meetings.

Sadly I am stuck in this current nightmare but one can dream. Maybe, just maybe, something new will pop up. Or maybe the world will end and the meetings come to the same end.

If the future wasn’t coming, today would get pretty dull.

]]>Tue, 20 Sep 2016 22:20:10 +0000http://thecodist.com/article/i-dream-of-somethingPhone Interviews Can Be So Painful To Dohttp://thecodist.com/article/phone-interviews-can-be-so-painful-to-do
I haven’t written much here lately due to the crazy workload at my job. Working for a big company can be really complicated and this project is the second highest profile thing we are doing this year. But being the lead iOS person I have to interview folks for supplementary contract positions over the phone.

Just to be clear, don’t send me a resume. I don’t collect them, they come through some giant process involving people, places and machines I have no connection to. All I get is something spewed out the tail pipe and I get to choose who to call and attempt to discern if they are worth trying out. If you send me a resume it will vanish into a black hole. If you are a recruiter the same response will be given passed through two black holes.

At my last job I interviewed people to replace me, in this case they had a number of recruiting firms who blasted me with every random resume they could scrape together. Oh the humanity. I got resumes for my iOS position which were clearly copy and pasted from random other resumes, often with non-iOS content. One even misspelled Objective-C completely (as in most of the letters were wrong except for the C).

I did a few phone screens on those who seemed vaguely acceptable. In this case anyone who passed would come in for an in-person interview. I had a list of questions based on everyday knowledge of iOS programming, nothing tricky or clever, but things designed to be something a person working every day on real iOS apps would know and for that job based on what I had been doing myself.

I still use part of the same list here, but I’ve added Swift questions and a couple simple testing scenarios (you have this and this and this and you do this and it crashes, why?).

The first question is the easiest softball question you could possibly ask: what is the string class named in Objective-C? I kid you not at least half the people did not know.

Out of about 10 phone calls at that last job one person got most of them correct, answered in a fashion that was obvious they not only understood the questions but could easily expand on them. We interviewed him in person and everyone approved. Stupidly they didn’t hire him because he wanted $10K more than they expected. I told them you won’t find anyone like this person again. It took them several months after I left before they lucked into another one, I guess they learned their lesson.

At my current employer one person answered intelligently, expanded on his answers, had clearly worked with all of these things and we hired him (contractor). He sits next to me and works independently and I don’t have to think about him at all. But we need another one.

So far the interviews have all been the same depressing thing. They don’t remember, they make up random stuff, they apologize a lot. It’s sad asking that first question and having it be wrong and knowing the rest of the interview will be terrible. I never like to just give up so I gamely ask all the questions anyway; maybe they were nervous and will get better. Sadly they never do.

A real working programmer who lives daily in code (even if it's at home) is able to talk about things, even if they don’t know everything, what they do know comes out easily. None of my questions are the equivalent of rocket science. I want to know if they can work on what we have here (which is a varied lot of things in both Swift and Objective-C) with the least amount of fuss as I have a full suite of complex things to write myself (the high profile thing) along with all the insane meetings I have to attend, and only a minimal time to help less experienced people on all the other things we have. I like helping people do things better or easier but I can't take away from this project too much.

I would think if you are applying to an iOS (or whatever it is) position you would at least take some time to prepare, read a few blogs on the technology, read some lists of common questions, something, anything! Even in past when I was on the other side I’ve always done a couple hours of basic prep to remind myself of stuff I might not have touched recently. I just can’t believe that people expect to be interviewed by a clueless HR person and hired immediately. I’m not a manager, I actually live in code every day, you can't fool me.

I was recruited to work here by my former manager at the travel company (two jobs ago) who already knew me and talked about me here for 18 months before the wheels of this sluggish beast finally creaked forwards. For me this was the easiest job to get ever though I wish I would have asked more questions! I had no idea how complex this place is and how high the profile is. This project has more zeros in it that everything I’ve ever done put together.

I remember failing a phone screen before too, one person at a familiar brand spent the entire screen grilling me on object-oriented theory which I wasn’t remotely prepared for and seemed totally pointless for the position (during my Java days). Of course soon thereafter they canned all of their devs and went completely to external vendors without having anyone who could even understand how development worked. So good thing I couldn’t explain OO theory clearly. Just in case for phone screens since then I look it up, you never know!

Sometimes I wish one could just dump a programmer’s brain into a database and run some queries. I guess that day might come in the future.

Now if this was a fulltime employee position for a long term you might want to do more in person interviews though to be honest all the overwhelming process at the Google and Facebooks of the world seem beyond overkill. To me a programmer sounds like a programmer, can talk endlessly about programming they do every day and talk in detail about the minutiae of projects they lived in in the past. I know I can talk about stuff I wrote 30 years ago still, maybe it got better with age but still in pretty decent detail. If I ask someone who doesn’t know what the string class is named will I get more than 30 seconds of detail?

A programmer should be able to tell if they are talking with a real programmer in 30 minutes or less. After than you just want to know anything special you care about. Taking two full days (I knew one guy who Microsoft flew in 11 times for interviews) is a terrible waste of everyone’s time.

If they don’t know the name of the string class you may as well stop right there.

]]>Tue, 06 Sep 2016 17:45:23 +0000http://thecodist.com/article/phone-interviews-can-be-so-painful-to-doThe Best Code I Ever Wrote (Part 1 of 2)http://thecodist.com/article/the-best-code-i-ever-wrote-part-1-of-2
This project was the most pressure-filled thing I ever did yet in many ways it was also the most fun. In the end it was also the best code I ever wrote.

In 1999 or so I was working for a consulting firm working on an application for the US Post Office, and my officemate was assigned to a big new project for a popular magazine. I didn’t really pay much attention at first since I was trying to avoid going postal (USPS was fairly painful to work with). The magazine had boldly promised the previous fall that in one year they would have a fabulous new website that would allow consumers to search their massive consumer product catalog, and especially a database of every make, model, package and feature of most of the world’s automobile manufacturers. It was a bold promise.

I knew it was a big deal since I heard the the magazine had hired another consulting firm who had worked on the project for six months before giving up and telling the magazine that what they wanted to do was impossible. Of course our CEO immediately said we can do it and a team started from scratch. The magazine had all the data in raw form. We (as in the team, not me, I was still postalized) built a database and a data entry system so that an army of 20 people could input and categorize the data.

They also started on the website itself, and hired some supposed expert on search engines who would build the crucial engine itself. Strangely enough he lived and worked on a mountaintop in Colorado or Wyoming (I forget which). We also bought the hardware (3 servers from HP) and were going to host it in our server room (no cloud back then).

So about 3 months in and with less than 2 months to go before the promised date panic began to set in and I heard lots of discussions and concern. The web application was built with WebObjects (I think Apple by now but maybe still NeXT), Enterprise Objects and the database was Oracle, all running on HP/UX. The search engine, like the app, was written in Objective-C, and had been delivered and installed in the application and put on the production hardware.

It was slow. Not just a little slow. 70-seconds-per-request slow. Apparently the “expert” had written the engine using just a few rows of data. Once it was exposed to the real database, which had a lot of data and especially all the automative data, it was dreadfully slow.

Of course our DBA and architect and everyone else not tied down started to investigate, especially the database query, which measured 4 printed sheets of paper long (I know the DBA stapled it to his office door). Nothing anyone could think of helped. No amount of indexing made any difference. People were beginning to worry that maybe it was impossible just as the other firm had concluded.

I remember asking my office mate, the architect, “let me take a look”. My project was at a slow point and I thought it might be useful to help out.

At this point I knew basically nothing which I think might have been a big advantage. So someone got me access to the database and gave me a brief overview, and of course I could play with the app itself.

What I learned first was how automobile manufacturers put together vehicles. There were features, from vanity mirror to heated seats to engines, individual ones, assembled into various packages. Each vehicle started with a base model to which you could apply packages. The packages themselves had rules for combinations: some packages required others (and), possibly from a set of choices (or), and some packages could not be combined with others (not). For example a package with an engine could not have another package with an engine, heavy duty towing might require a bigger engine from some package, etc. The magazine had organized the data across all the manufacturers with a categorization scheme that would allow search and display so that the user could search for any combination of features, model types and cost across all manufacturers. This also worked with non-automobiles but that wasn't all that exciting. Automobiles were the killer feature.

Now the data in the database contained the features individually from each manufacturer, combined into packages, the rules were encoded into the database, linked to vehicles they applied to across a manufacturer’s models with a complex web of categories. Once I stared at it for a bit I realized the data was a poor match for a relational database, there was no relation that went from a feature and got you to a vehicle model. It was more of a description of how to derive the actual data rather than the data itself. The database schema had been built in a hurry and no one really took any time to understand the nuances of the problem since the time was so short. It might have been possible to model the data better but by this time an army of people had already entered the data into the current database and there was no time to do it again.

So while everyone was trying to hammer the existing code I began by extracting the data from the database so I could see how I might model it different. Of course I could not change the database since everything was complete otherwise. So the solution would have to be something else.

Now prior to working for this firm I wrote and sold a commercial memory allocator and heap debugging library called HeapManager for MacOS (prior to OS X). So I figured maybe I could organize the data in memory and search that instead of starting from the database directly.

At this point no one expected much of me. There were only 4 weeks to go before beta and 6 before the promise date.

So I wrote an extractor to pull out of the database all the relevant searchable data and the encoded rules that described how the packages could be combined. The search feature of the app would let the user pick from categories of features and other things like 2 door vehicles, or trucks, and specify a target price. The results would be a list of models across all the manufacturers that could be customized by any sets of packages that were legal to combine. The idea was you could look for whatever combo of things you wanted and it would figure out what an auto manufacturer would be able to custom build for you. If this worked it was something even the auto manufacturers didn’t have as far as I knew.

I saw that the package rules created a sort of tree where the relationships to the children were and, or and not. So picking a package you could traverse its children but you would have to follow the boolean type. If the child was ‘and’ you had to move down, if the child was part of an ‘or’ you had to move down all of its siblings, if the child was ‘not’ you could stop. Each package had children that described all the potential and required child packages until you exhausted all the possibilities. So starting at a feature like heated steering wheel you could find all the packages that included that, traverse the children for each recursively, and eventually find all the models that were connected to those packages.

So for example feature a was in package b & c, b required one of d, e, f and c required g but not f, d required h, e required i; you get the picture. Of course the feature likely existed in each manufacturer so it was a huge forest.

So now I had a good idea of what I was needing to figure out. Given a set of features and other restrictions (like pickup truck or 4-doors or under $20,000) could I come up with results for every conceivable query and do it in no more than a second?

Briefly I thought of generating every possible vehicle from the data but the combinations were simply too large and I knew we were limited to just the hardware the customer had authorized. I also didn’t feel confident I could verify I was actually generating them all either.

Today of course this is the correct answer! But not in our situation and in 1999 the options were pretty limiting.

At this point I was fairly confident I understood the problem. I then analyzed the existing search engine (still chugging along at almost a minute per query) and realized not only was it stupidly slow, it was also very wrong. By hand tracing my data I could see that its answers missed a lot of correct results but also included a lot of completely bogus ones. There was no fixing it.

So I presented my analysis to the team which was pretty desperate so they told me to go ahead and see if I could build a replacement while they continued to try to fix the original. By this point I had 3 weeks left.

Stupid me thought that back when I switched registrars I had turned on auto-renew. Nope, dope.

Thankfully I caught it immediately but they had already switched the DNS to point to a landing page and switched again when I paid up and DNS all over the planet got mighty confused. Most people did not notice although my home DNS (Google's) didn't show my server until the next morning. I checked with whatsmydns.net and it mostly showed the correct server appearing for others.

So the next time 170,000 people come visit you make sure you put out the welcome mat and keep your domain up to date!

Just call me Homer Simpson aka The Codist.

]]>Tue, 12 Apr 2016 19:20:10 +0000http://thecodist.com/article/into-every-life-some-d-oh-must-fall-occasionallyHow Many People Does It Take To Ship Software?http://thecodist.com/article/how-many-people-does-it-take-to-ship-software
There are a million jokes along the line of “How many _____ does it take to screw in a lightbulb?”

Sometimes I laugh at work at how many people are involved in the project I am working on. We have me and one other programmer and 20-30 other people that we can count for a three month or so project. This is after about 6 months of creative approval cycles with an uncountable pile of VP’s; yet changes keep happening despite all the requirements for deciding everything in advance. On top of that it is not too dissimilar to a project done by a different team (though the code is not reusable) that is about to ship.

Why so many people? It’s a mystery why bigger companies have bigger teams to build things that are not so big. I’ve come to the conclusion that the more people you put on a project the more people you need to manage the people you put on the project plus the people needed to manage those people, and so on. “The bigger the team the bigger the team the bigger the team.”

Back in 1988 we built Deltagraph which wound up leading its market segment (chart/graphs for print) yet the entire team was 4 programmers and one QA on my team, and the publisher had one QA and the product manager. That was it, and for an application that was similar in size and complexity to Excel by 1993. Eventually the publisher added a couple more programmers on the last version we worked on.

Two jobs ago I worked for a brand name travel company (now sadly just a brand of someone else) with around 1,000 or so employees worldwide. Our mobile team had about 20 but by the last year we had grown to 15% of the gross revenue and if we had continued would have been 20%. We supported 7 different applications (native and web) and a mobile API between us. We had QA, a product manager, designers and programmers mostly in one place and one manager to rule them all. Our API and web apps ran on AWS which we managed ourselves. The rest of the company had one product (the main web app) in the US and one in Europe. We averaged 70-80 releases of things every year and the main web app barely changed a couple times a year.

When I worked as a consultant (not contractor) fixing customer’s problem areas I often worked by myself being analyst, project manager, architect, programmer and DBA all at the same time and often I had to design non-computer processes as well. I remember working on a large project for nearly a year with just two people doing everything.

Some times I am amazed when small startups crank out amazing products with hardly anyone and little management but since I’ve been there I can at least imagine it. I’ve always thought that the smallest possible team can accomplish great things, provided they are in control of how and what they are doing. Usually in big companies you wind up with everyone wanting to control everything, massive division of labor into small slices of responsibility in order to let many teams have a piece of the pie.

The more people you have in any project the more communications you need, the more management you need, the slower information is disbursed and problems reported. You have to have more process to ensure that anything will be accomplished. Of course this all costs more money and time and often you have to do less just to get something shipped. It’s easy for everyone responsible for all these people to worry about unknown problems biting them in the ass so every decision becomes very conservative and cautious.This of course makes shipping difficult, expensive and often drags things out for a long time. Add to that memories of previous projects that had the same issues and things get even more cautious and slow.

Compare that to small startups who aren’t held back by caution, heavy process, siloed management and worry. Even our travel mobile team was more than willing to take risks, to use small teams and try new things like AWS instead of building empires despite being part of a large ponderous entity. It can be done in such an environment: this team started without any support from anyone as management just wanted mobile to go away and assumed it was a fad, which made it possible to stay lean even as we brought in more and more revenue.

Look at any government project and you can’t help but laugh at how many people get involved in everything. I remember at the consulting firm I worked for, two of the guys had worked on a DOD project involving some kind of healthcare initiative where they were 4 or 5 levels of sub contractors down from the primary contractor; they often had no idea what was going on or what they had to do. The recent laughter at the $350,000 app for the TSA which was nothing more than two arrows and a call to random() was an interesting example. One place I worked as an architect had a project I estimated at 2 person-weeks of coding. Six months and dozens of meetings later to write a 120 page requirement documents resulted in the same estimate. We could have built the app 10 times over. But what would all the people at those meetings have done?

I have coworkers who rarely get to write any code and they are pulled into so many meetings and calls they barely qualify as an engineer any more. The time spent coordinating and explaining and planning and scrumming and preparing for more of the same leaves little time to actually deliver anything.

Thankfully for all of my 35 years as a programmer the only large team project I ever worked on was three months in Mexico in a real death march that never went anywhere. I’ve stayed away from anything otherwise I can’t count with my fingers. Sometimes you need more people and more planning like building an OS but most of the time fewer people is always better, again provided those few people can control how and what they are doing. You can’t use minimal teams and then pile on process and standards and reporting and meetings and the like, and expect the few to make it work.

Even once the code is done at my current place there are multiple teams who have to meet and approve and fill out forms and coordinate and get sign-offs from various VPs in order to push anything, even to test environments. It’s insane how much process there is. I imagine there are many places out there that are no different or even worse. It does provide for lots of employment.

I am also sure that many people feel that all of this cautious complexity is necessary, or at least it makes higher management feel more secure. Some of this may be necessary sometimes (I haven’t ever written code for a nuclear plant) but given all the projects I seen with large teams most of them never really justified all the reams of people that were involved.

You can never know what you would have accomplished if you had had an extremely lean team with a lot more freedom in how they went about doing the project but often companies don’t want to take the chance. Building empires of people with narrower and narrower responsibilities gets more people involved and makes the leadership feel important. Do you really need creative/design, animation, copy, project management, product management, delivery management, development management, promotion management, operations, DBA, various levels of QA and others I don’t even know plus several layers of VPs to ship the work of two programmers?

I bet you really don’t. I miss the days when the team was small but the results were big.

]]>Tue, 05 Apr 2016 21:34:14 +0000http://thecodist.com/article/how-many-people-does-it-take-to-ship-softwareMy Biggest Regret As A Programmerhttp://thecodist.com/article/my-biggest-regret-as-a-programmer
A little over 20 years ago I was at a crossroads. My second company was petering out when our 5 years of building Deltagraph for the publisher ended (they wanted to move into the nascent internet space). At that point I had 13 years experience as a programmer but also 9 years or so experience running a company (at the same time).

I no longer wanted to do both. My first company 85-87 not only built a new kind of spreadsheet program but also published it ourselves. I led the company, did all the press interviews, managed the investors, did all the usual business stuff and also was one of the three programmers and the UI designer. After we shipped the product in early 87 I also wound up in the hospital. Trying to be both leader and programmer was simply too much.

So at that point in 1994 I could have gone either into technical management or continued as a programmer. I chose programmer because it was easier. Today I now realize how wrong I was despite all the great stuff I’ve been able to work on and ship over the past 20 years. Going towards the CTO/CIO/VP Engineering route, which was fairly new back then, would have been a much better plan.

I was in the Bay area for a year around 1995 and worked at Apple for the last half. Apple looked to be falling apart and I left to return to Texas as I didn’t want to see my favorite company die around me. Big mistake.

Not only did Apple begin a huge turnaround a year later when Steve came back, but the whole Dotcom explosion happened. Being both an experienced programmer and leader who understood what it took to deliver (we did 9 major releases of the apps during my time, all of which I built the master floppies for, with no need for hot fixes which were hard to do then anyway) I can only imagine how in demand I could have been. Once you get to the level of one of those titles you can keep moving forward and up.

My sister started as a programmer 30 years ago but jumped into management within the first year and has been a VP at a big company for the past 15 or so years. The huge parent of the travel company I worked for a couple years ago had a CEO who started 15 years earlier as a programmer. Of course these types of jobs can be hard and unpleasant but for that the renumeration is way greater. My sister has 10X the assets I have.

Over the years I’ve seen how little ability you have as a programmer, no matter how good you are, at making a difference or changing things that are broken. I simply didn’t realize how little room you have to advance as just a programmer (or even architect or the like); the power to change exists at a level not available to you as a mere delivery device. Add to that the financial benefits, the higher likelihood of substantial IPO participation, and all the other things you gain access to, and being a programmer means you have to be happy with the opportunity to build cool things.

Over the years the worst places I’ve worked or helped as a consultant for those 5 or so years I did that were almost always due to inept, incompetent or downright idiotic technology management. There isn’t enough room in this blog to list them all.

Take the VP of engineering for a bank who remarked that he didn’t need to understand technology as he managed people, yet still made technology decisions. The CIO at the same place never believed anything his employees told him but believed everything vendors told him. Of course we knew he was taking kickbacks as we kept buying things we had no use for and he kept writing articles for them relating how wonderful their products were for us. Yet we used almost none of it. Some time after I left he was fired and perp-walked out of the company yet immediately got another similar CIO position.

The worst job I ever had started out as what I thought would be awesome. A post-startup had a successful niche in their industry; both they and their arch-rivals (different niche) both wanted to launch into a broader public market and the market was heating up. I was hired as a second programmer. The other programmer and manager had been hired to build a new broader online store as the existing one was too inflexible and slow for a big market. The company had zero technical leadership otherwise, the CEO and the other two founders had no technical experience or knowledge. The programmer constantly talked about how wonderful his backend code was and the manager supported him. I built a front end piece, put up demos, checked in my source every day. When I thought it a good time to integrate I discovered the other programmer after 10 months had checked in—nothing. When I pointed this out the manager said “he never checks in anything until it’s perfect”. Yet no one called this out as stupid other than me. I spent the next two months trying desperately to get the 3 founders to bring in people who could actually deliver (I knew several people) but they were afraid to make any changes and admit they had screwed up in hiring these two guys. Eventually I gave up and left.

A year later after still getting nothing from this guy they fired both of them. They tried to hire some consulting firm but got nothing from them either. By this time it was too late. The rivals? They became a billion dollar public company and I see their commercials on TV sometimes. I always want to throw a shoe at the TV when I see them. We had everything but a damn store and in reality actual technology leadership. If I had been such a person instead of a programmer I would have had the track record and clout to make it happen. But all I was was a programmer.

I could go on and on but the key is that you can’t make changes in how people do things in a technical sense unless you have the ability, the authority and the opportunity. Once you make that call and assuming you find the right places to grow, the sky is really the limit.

When I was on TV (Computer Chronicles) in early 1987 showing our product Trapeze the other presenter was Mike Slade who was product manager of Excel. At the time young me thought him some random marketing weenie (young people can be pretty stupid). Yet he started all these companies later including ESPN, worked for Apple in various leadership roles, was a good friend of Steve Jobs and started his own VC firm.

And today I am still just a programmer. Who’s the weenie now? I doubt I will ever be able to really retire. Thankfully I am still good at delivery (I was recruited into my present job by a former manager who needed what he knew I can do) but still all I will be until I croak is what I am now.

Being a programmer for nearly 35 years and still being able to get things done and ship is still fun and I’ve been able to work on amazing things over the years. But I can still feel the regret of not seeking the challenge of just leadership. In some ways programming was the easy choice. Given how close I got to the whole Dotcom timeframe, or even the return of Steve to Apple, and still had recent leadership experience, I could have been almost anything.

So yes I regret not taking that choice and seeing where it would have led me, yet I would have missed all the fun of writing code and the soul-draining jobs that often come with it where you can’t really fix anything.

I came to a fork in the road and took the one less traveled. Perhaps now I realize why.