zVision is the future!
This internal memo was sent to SRS Software this morning. The points are important enough that I wanted to cross-post here.
Team,
I know there has been a lot of frustration over the last year as we have been working on zVision, the web platform, and ReEn. The shift we are making takes us from creating products to the creation of a platform.
So far, most have only felt the pain of the transition and have not seen the advantages. I promise you that this transition will be worth the pain and frustration. We are on the cusp of realizing a payout and it will be huge!
A guy who worked at Amazon and is currently at Google recently posted what was intended to be an internal memo on this topic. Everyone should take time to study the attached memo (http://steverant.pen.io) and understand the points that are made.
Here are a couple of threads where people are discussing Stevey’s memo that you may find useful:
- https://plus.google.com/112678702228711889851/posts/eVeouesvaVX
- http://www.reddit.com/r/programming/comments/l9ehj/steves_google_platform_rant/
I will continue to do everything I can to clearly communicate the amazing direction we are headed.
- zVision puts us at the forefront of the technology industry!
- zVision is the platform we need to carry us for the next 10+ years!
- zVision will give SRS the flexibility and agility to dominate in our chosen market!
You are welcome to send me questions or comments privately. Alternatively, I have cross-posted this to my blog and you are also welcome to publically comment there.
- Nate
Nate Zobrist | VP of Software Architecture
Service Repair Solutions, Inc. — Revolutionizing the Delivery of Service and Repair™
770 East Technology Avenue, Building F | Orem, Utah 84097
Phone: (801) 437-5846 | Fax: (801) 437-5899 | Cell: (801) 788-4789
www.servicerepairsolutions.com
Creating Apps Should Be Trivial!
At Dreamforce '11, a presentation I particularly enjoyed was given by Ryan Smith from Heroku. Titled Designing for the Cloud: The 12 Factor App, Ryan discussed some fundamental design patterns and practices that have made Heroku successful.
An interesting analogy that was made compares applications to swiss army knives. The analogy is relevant to SRS and provides a great visual depiction of the work we are doing as part of our SaaS and SRSWP initiatives.
Historically our applications were designed as large, monolithic beasts. Like this knife, every feature that could be imagined was rolled into one of our flagship products. This design meant:
- Duplicated effort because there were no shared components between product lines.
- Intense effort required to join the team due to the large, interconnected designs.
- Even small changes were risky and had the potential of destabilizing anentire product.
- Management of each product line required enormous effort to tightly coordinate development and release of new features.
Contrast that complexity with a design where:
- Components are small, independent apps that work together (like Linux tools).
- Each component delivers specific functionality.
- Touch points between components arewell-defined contracts.
The workflow enabled by this component-based architecture is truly liberating.
- Small teams (perhaps even a single-person team) can build on top of the shared platform to quickly create new products.
- Most products do not need to worry about operational infrastructure, databases, etc.
- Products can take advantage of shared services to quickly enable powerful features in innovative ways.
- Products can tap into shared repositories of both customer-generated and catalog data.
- Existing products are simpler to maintain and introducing change is far less risky.
- A smaller codebase means that the project is much easier to grok.
- Well-defined contracts that have robust automated tests written against them mean that each component can be released independently with confidence.
- Teams can work more efficiently by choosing technologies and frameworks that are tailored to fit specific needs.
- Using standards-compliant web services for an API means that apps written in Java, Ruby on Rails or Node.js can access shared services as easily as a legacy, .NET application.
Following a component-based approach will make the creation of new apps a trivial exercise. It will free us to focus on solving interesting problems rather than being bogged down by operational overhead. The quality of our offering will increase as we become much more responsive to customers.
Applying these principles means something different for each of our existing projects and teams. What remains to be done for your team to fully benefit from this component-based design? What new functionality would you like to see exposed by the SRSWP?
Contract Definition and Stability
In my first zVision presentation that was recently given at each of the SRS offices, I identified one of Engineering's current problems as an "absence of trust" between teams. This phrase caused some confusion that I would like to clarify.
Let's say I want to write an app that integrates with the del.icio.us bookmarking service. My application will be reliant on their public API. So, for this venture to be successful:
The API's Contract Definition is essential:
- Method descriptions, examples, limitations and assumptions are all necessary and are included as part of the API documentation.
The API's Contract Stability is essential:
- Breaking changes should be very rare. Even with a disclaimer stating that it may change at any time, there is an implied level of stability in any published API.
- When a breaking change to the API is necessary, backwards compatibility will be provided. That's why their APIs all have "v1" in them!
Within SRS we should think about cross-project integration similarly to integrating with external services like del.icio.us. Except in very rare situations, touch points between products are limited to APIs (i.e. massively-versioned web services).
When I referred to "absence of trust" in zVision, I call attention to the fact that we do not yet have the requisite level of Contract Definition and Contract Stability in our APIs. Without both definition and stability, I could not trust the del.icio.us API enough to base my app on it. The same is true for building on SRS-internally produced services.
Since the end of 2010 and through 2012 we are making a large investment in re-architecting our products based on principles of SOA and SaaS. Absolutely essential to success are APIs which are both well defined and stable. Once we have those things, we can trust the services provided by other SRS teams as much as we would trust del.icio.us.
My New Job (Title)
It has been quite a long time since I last posted anything to my blog. It's not that I haven't thought about it or that I haven't had time (though life has been busy). I've struggled topically with what to write.
This blog was started with the intent that I would share things about my work: creating software. But, over the last year my job has been in a fairly constant state of flux with my responsibilities shifting radically from what I was doing previously.
I love being a software developer. I love the problem solving that the work entails. I love being in "the zone" while writing code. I love creating something that others find useful and I like to think that I am fairly good at it. Wishful thinking? Perhaps. But, at least one other person has thought me passable, so I choose to believe. 
At present my job title is VP of Software Architecture. In my new responsibilities I still get to solve incredibly complex problems and derive a lot of satisfaction from it. In many ways the things I work on now are more intricate and stimulating than what I did previously. The only downside is that I rarely get to ride "the zone" via coding anymore.
Two years ago, if someone had described my current job to me and asked if I wanted the position, I would have turned them down outright. I derive so much pleasure and satisfaction from writing code that I could not have imagined wanting something else. I was firm (and vocal) in my commitment to avoiding "the management track." How then did I end up here?
I joined Mobile Productivity, Inc. (MPI) in January 2004. The people were great and the work was both challenging and interesting. But, after a few years I started to grow bored. Nothing had really changed, except that I wasn't creating new software anymore. I was responsible for a significant portion of our flagship product, ARGIS (since rebranded MPI Edge), but I had rewritten most of the code several times and just wasn't being stimulated the way I once was. I decided to leave MPI to go work for another startup named Podango.
Podango was a good company in many respects, but like many startups it wasn't able to thrive and closed at the end of 2008. Friends at MPI heard that I was in the job market and offered me a position. I was a bit hesitant, but a lot of new things were happening and I felt good about returning.
<sidenote>
Internally at SRS, this period of my career is jokingly referred to as my "sabbatical."
</sidenote>
Somewhere in all of this, MPI acquired several companies and was renamed Service Repair Solutions (SRS). We've grown from 25 people in a single office to just under 600 total (including offshore teams). The Engineering department alone has over 200 people spread across offices in Utah, Minnesota, Uruguay, Vietnam, Las Vegas and Russia.
I'm not worried about growing bored again any time soon. My job is awesome!
Source Code Management
Note: This blog post was originally posted to an internal SRS blog on February 09, 2010. The post was intended to address specific issues, but I do strongly support the idea of "commit early and often" as a general principle.
Source Code Management
Source control is a fundamental part of software development. The benefits of using a source control management (SCM) system are numerous and worthy of their own blog post. But, I have noticed two significant problems with the way that SCM is currently being used on many of our projects:
- ChangeSets are frequently too large
- ChangeSets often contain code that shouldn't be committed
ChangeSets Are Too Large
I am frequently guilty of working for days on a particular task without committing any changes to source control. I like to wait until my task is completed. I don't want to break the build, and I don't want to commit broken code that might impede others. But, the biggest reason that I avoid committing my working code is that I don't want anyone to see it until I'm finished.
There are several problems with monolithic commits, including:
- Integration headaches: large ChangeSets increase the odds that changes will conflict with someone else's changes
- Useless file history: comments on large ChangeSets are, of necessity, more vague and less likely to convey useful information
My preferred version control software at the moment is a DVCS. DVCSs offer many benefits over traditional SCMs, but one of the best is easy branching and merging. A DVCS allows me to work like this:
Branch per Task
Every development task is a new, independent branch. Tasks are merged into the permanent main branch as they are completed.
(from Coding Horror)
Each time I am ready to begin a new task I create a branch for all work on that task. I generally have several active working branches that I can easily switch between. I check in code often to my working branch, rarely going more than a few hours between commits. Once I have finished working on a particular task, I merge my completed code back into the shared master branch. I am able to make frequent commits without breaking the master branch due to incomplete code.
Unfortunately, TFS does not easily support this style of development. Creating branches is inconvenient, and merging code between branches is torture. Although I would love to recommend that SRS adopt the style of development that I've described, I just don't believe that it is feasible with current versions of TFS. Given the painful nature of branching and merging in TFS, I don't see a better alternative to our current branch per-release strategy.
Given that TFS doesn't provide easy branching and merging, here's what we can do to find a happy medium. We should not check in broken code, but we shouldn't hesitate to check in code that is incomplete. Especially for new functionality, there shouldn't be any problem checking in a stub method that doesn't do anything. There are very few, if any, situations where we would be unable to commit our working code to TFS once a day.
There will no doubt be times where checking in small, granular ChangeSets will not be practical. There will be times when some of our tasks require us to break the application (not the build though!) in order to complete a task. However, it is my belief that with a little planning these times should be brief and infrequent.
It would be foolhardy to ignore the problems that accompany frequent check-ins. As the number of developers working in the same code base increases, so too does the probability that someone will check in something that will disrupt everyone else's work. This leads directly into my second topic: We must be aware of the code that we are checking in.
ChangeSets Contain Code They Shouldn't
When it is time to commit code to TFS, it is not uncommon for developers to simply check every file listed in VisualStudio's "Pending Changes" window and commit all outstanding changes. Although VisualStudio makes it incredibly easy to follow this bad practice (Why are all modified files checked by default?!?), we need to stop doing it. Sometimes debug code is committed and leads to problems that are only discovered after our customers have the release. Sometimes builds are broken as csproj and sln files are inadvertently modified. Sometimes it simply messes up the file's history (TFS always increments the version and updates the file's history, regardless of whether anything in the file has changed). These things should not happen. When checking code into SCM it is the developer's responsibility to verify every change that is being made. The developer should diff all changed files and verify every change that will be committed.
If anyone has found and enabled the option in VisualStudio to "Check in everything when closing a solution or project," please disable it immediately. No good can come from that option!
In some cases you may imagine that these procedures don't apply to you because you are the only developer on your team. That is a false assumption. Code should always be written for the long-term. Code should always be written and commented in such a way that another developer can pick up your tasks at any time. Julian Bucknall, the CTO of Developer Express, recently posted a thought to his blog that precisely expresses the point I am trying to make: Assume your code will be public. I am as guilty as anyone — probably more so, actually — of some of the bad practices that Mr. Bucknall describes. Edge Legacy is full of funny names and informal comments that I wrote to amuse myself. As we consider publishing more of our APIs for external consumption, it is increasingly important that the code we write properly represents the professional nature of SRS and increases the trust that our customers have in us.