What was it like running a development shop In San Francisco when 729 first got started 15 years ago?
This actually dates back even further than that, I am a big believer in the idea that computer science and software engineering are separate but related things that overlap and that the future of software engineering, to some degree, is going to come from people who are critical thinkers who are Liberal Arts majors. I think this is also how we can address some aspects of the diversity problem in tech.
There’s always going to be the element engineering to all of this, but I think people see that software engineering is more like Lego, an erector set, and building things from the tools available as opposed to just computer science. Nikos Lambridis was my mentor and his theory was that, at a time when people were in that, “Don’t touch the computer. Don’t shake it, don’t move it; you need to be a qualified computer scientist,” He basically gave us permission to play. “Nobody’s going to die. Nothing’s going to explode. Do whatever you want to do and just try to understand why it fails when it fails.” I think he was basically teaching Agile development before anybody had ever thought of it. He was way ahead of his time.
The Wild West of the Dot-Com Era
But how was it different 15 years ago? Well, I started this for the wrong reasons. I wanted to run screaming from the designers, and do it the right way, and make this programmer’s paradise and all this other nonsense that I don’t necessarily believe anymore. That’s been part of the experience.
It was different in the sense that there was very little work because of the dot-com bust and the post-9/11 economic situation. At that time it was also the norm for companies to hire development shops like ours to build their entire application, start to finish, and to continue to pay an outside shop to do that. Now we definitely get a lot less “Greenfield” development projects, as people come to us with their basic ideas already formed.
I think the thought process in 2003-2004 was much more along the lines of, “Western developers are expensive and they’re just code-producing machines. We don’t need any of that.” A lot of companies started going to India for their development and ultimately didn’t get the results they were looking for. Once big companies realized this and startups realized that there was probably a million dollars per engineer in the valuation of their team, companies started outsourcing less. Not that people have gone entirely away from outsourcing, but I think they started to bring things back in-house over the course of these 15 years. When the financial crisis hit in 2008, I was convinced that the agency model was broken. Maybe to some degree, it was.
I still believed that, if you were going to make an agency work, it had to be a one-stop-shop; that people were looking for across-the-board consulting. We are a consulting firm that does systems integration, application development, now design, maybe someday marketing. All those types of things. That didn’t really exist 15 years ago.
There were people who claimed it did, but they were design and marketing shops who had a programmer or two fenced off in the corner who were overwhelmed, they had created disasters that were really hard to fix. These companies could get big clients. It’s how we got into working for companies like Suzuki and Verizon. We were able to step in and help them with implementation while learning a ton along the way. One of the other big differences, in the dot-com boom, was time and materials for not a lot in terms of functionality. We were basically making webpages for big bucks in those days. Maybe the webpage processed a form, but overall they were very basic., We were reinventing the wheel with every client, not at all thinking in a modular, library-driven fashion. There was no easy way for systems to communicate with each other. It was just, “Hey, duct tape and baling wire. Get it out the door. Let’s collect the checks and move on.”
It was the Wild West, really, and that applies to how we were dealing with code and how we were dealing with bills, too. Integrated quality source control and collaboration just didn’t exist. When the dot-com bust happened, a lot of these companies felt like they’d been ripped off. They had gotten big bills and had not gotten a lot in exchange for that money.
Fishing Derby
Then it went to a fixed-bid model for probably the next six, seven years. Maybe more than that. That crushed so many shops because then it became like Fishing Derby, it was, “How fast can I go get my share? I don’t care if we have to work 24 hours a day; that’s what we’re going to do.” You ended up with a lot of garbage and you ended up with, “We bid $10 on this and we did $100 worth of work.” Well, as you can imagine, shops don’t stay alive that long.
In this middle era between dot-com and whatever you wanna call this era, that’s probably the biggest evolution from a financial perspective; the customer got ripped off in round one and the agencies and shops got ripped off in round two. There were not a lot of people left standing at the end of that whole thing.
Era of Agile
Companies started to internalize their engineering, putting 729 Solutions in an interesting spot going back 2010, 2011, 2012. I was really starting to wonder if it made sense to have a shop like this anymore. But then Agile starts to come into this a little after the dot-com bust and the Fishing Derby and we started exploring formalized Agile approaches to development. I remember somebody saying somewhere, reading it somewhere, that as soon as somebody figures out how to bill Agile, it’ll be amazing.
It was true because Agile did not work well with fixed bids. In the dot-com era, we sent out invoices and the client had no choice but to accept them. In that middle Fishing Derby, the client would back up the dump truck with scope creep. You’d bid $10, do $100 worth of work, and be out of business the next week.
Our security blanket became that Agile approach and now we can effectively bill time and materials because we can give the client transparency. The platforms and the tools that exist now have opened the door to doing things that couldn’t be done before.
There’s now a way to show them the backlog so they can clearly see what it is we’re working on and what the ramifications of new scope are. We’re using that backlog immediately after the scoping process to make our bid, which is why our bids are now much closer, so we’re not missing the mark. When the client adds scope, they can make an informed decision about, “Is that worth paying for? Do I need extra money for those things that are now at the end of the backlog?” That has, for the most part, resolved that.
It will be interesting to see how Agile best practices evolve and change in the next 15 years of software development and growth in San Francisco. Software development is an ever-changing landscape, as new technologies are developed, and it’s exciting to think about where we will go next with 729 Solutions.
