“Stasis equals death.” I picked up this phrase from a really good book on screenwriting, and found that it absolutely applies to the software development world. It applies because it is utterly true. For developers of modern software, products are either under active development or they are dying.

This dynamic was clear in Apple’s transition last year to iOS 7. Within a few weeks of the update, most of the top apps were updated to the new look, and those developers that didn’t felt heavy pressure from their users. Look at anyone’s iPhone home screen months later and there are likely no iOS 6 apps on it.

The apps that were not updated now feel old. They still work as intended, but they no longer meet the expectations of their users, and as a result, they might as well not exist.

In the world of traditional enterprise software we see the same issues. Projects to develop or enhance an application finish, the operations team is (hopefully) trained, and the development team moves on to the next project. Sometimes on the same application, sometimes not. Either way, the project in production might as well not exist to the developers unless it breaks. After all, they have the next big project to worry about. The application enters stasis.

This leaves the users out in the cold. If they have changes for the application or issues that they need fixed, they must submit their issues to the ops team and feature requests to the product manager, or the roadmap committee, or whatever bureaucratic madness the governance folks can cook up. The timeline on addressing those requests then tend to run in months, not days. Even good software at this point starts to feel old, and broken.

It’s not just the users who are left out, either. As requests for work on the app stack up, and the next big project holds all the attention, a technical debt stacks up on the application in production. The issues may not be visible to the project team, or they may be known but “de-prioritized” in favor of the existing roadmap. Either way, this team runs a very real risk of launching a new iteration of the product that is even further away from what the users actually want and need. Even scarier is this simple fact: the longer these projects take to complete, the farther away they can stray from the users’ actual needs.

I know, right now you’re shaking your head and thinking, “It’s a good thing I don’t have this problem, because we are Agile.” Well, you might be right. Maybe.

Agile as a idea is a good one, maybe even the right one. But ‘Agile’ as sold by consultants and book publishers is not always the answer. There are a lot of people who will disagree with this, but it’s usually because they are selling Some Agile Way™.

Agile is nothing more than a set of ideas, ideas that build a culture. Merlin Mann talks about this concept in the latest episode of Back to Work, but the culture you create will define every aspect of your organization. Adopting Agile methodologies can help, but only if you are committed to building a culture that really believes in the idea of agile. Either way, and agile approach will not solve our problem by default.

So our problem remains. How do you avoid software stasis? By focusing your work on the product and not the project. This idea is not new, but it should be reconsidered by most of the software development world. Your primary concern should not be the project, but it should be the application.

There are many implications of these ideas, but product ownership can be implemented through a few simple concepts:

• Organizing development teams by product. Each application or service has it’s own dedicated team
• Tracking and scoping requirements by product, not project. For strategic initiatives you certainly need to have some mapping of the initiative’s requirements to the product requirements, but the system of record should be at the product level
• Projects will come and go, but the product teams endure, as does the product feature and fix backlog
• The product team must really own the product, and be in a direct relationship with it’s users.
• The development process must trust the team with ownership of the product

This breaks applications out of stasis. In this model, the product is never “done,” it evolves. With the team and work focused around the product the developer and his users can really own and drive the product forward together, without the long lag times of the project focused timeline. It puts the software and its use at the center of development activities.

This idea does not solve all the problems of a dev team. Like all things in life there is no silver bullet. But by viewing products as the key organizing factor, an organization can focus on the constant changes required to keep up with users evolving needs and demands. Isn’t that, after all, the key mission of a development team?

When solving any problem, we tend to look to the simple answers first. This is a good response, and one that should be nurtured. But can easily be misled by that simplicity. This typically happens in two ways. First, we think the simple answer means less time than other answers. We tend to equate simple with fast. Second, we assume that a simple answer is easy to implement. We assume that what is easily understood can be easily done. We equate simple with easy. As a result, we often misunderstand the impact of a simple answer to a hard problem. Because, truthfully, simplicity is hard work.

Let me make this more concrete. Take the idea of a microservices architecture, something I have been thinking about a lot lately. The microservices architecture is “an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

This is a simple idea. In fact, most laymen will be able to grasp it with about 10 minutes of explanation, and IT professional should be able to grok it in a matter of minutes. The idea is straight-forward and elegant. Break a single system down into multiple, small systems. Put application logic into the services, not the data or transport layers—”smart endpoints and dumb pipes” as Martin Fowler puts it. Call the services asynchronously, and run each of them independently. The concept is not complicated.

But implementing this idea is hard work. How do you deal with decentralized data stores? How do you coordinate operations between services without tightly coupling them? What about managing API documentation? Automated testing and deployments on multiple frameworks or platforms? All of these questions sit squarely in the middle of the microservices concept and must be answered.

With all of those questions in mind, is the idea still a simple one? I’d say so. The idea is still clear and easy to understand. But it doesn’t look easy now, does it?

One of the best lessons a good developer or architect should learn is how to continually ask the question, “then what?” Always push to the next question, to the next decision. Consider each one fully in turn, and then in light of the whole. You cannot be satisfied with the simple, obvious answer if you cannot work through all of its consequences. Don’t be fooled, in the software world simple is never easy. It’s hard work.

Scott Hanselman quotes Eric Meijer:

JavaScript is an assembly language. The JavaScript + HTML generate is like a .NET assembly. The browser can execute it, but no human should really care what’s there.

Yeah, this feels right to me. I know many folks had problems with this observation and this post from Scott, but I think it’s dead on.

Honestly, who likes plain JavaScript? Actually, since the advent of Prototype and jQuery, who even writes vanilla JavaScript? I bet the number is lower than you’d think. And there is a simple reason: like assembly was for early computers, the language is an efficient and effective language for the web, while being hard to read and hard to write.

I know, I know, hard is relative. I’m sure it might be easy for you because you’ve been writing it since 1996, but it’s not that easy for everyone. And honestly, wouldn’t you rather write in something like CoffeeScript instead?

The beauty of new tools and language like CoffeeScript and its ilk is in the layers of abstraction and personal choice they offer for developers who still have to work with the universal scripting language of the web. Just like languages that compile to machine code, we are now compiling other languages into JavaScript. And I think that’s a great thing.

Manton Reece on the recent App.net announcement:

There’s no shame in shooting for the stars and missing. I’m thankful that even as the founders tried a few things outside micro-blogging over the last year, they never compromised on their original mission for the service. They never sold out users or developers, and the servers hum along in testament to that fact, as if nothing that’s good will ever really change.

I agree with Manton. I’m glad they took a shot at redefining the model for social media platforms. I’m glad they stuck to their promises even when the numbers did not go the way they, and many of us, wanted them to.

In the long-term, I don’t think an advertising-centric business model will work for the social media players. Or, should I say I hope it doesn’t.

Thanks Dalton and company for taking a run at this.

Martin Fowler on the evolving practice of developing Microservices:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

He goes to describe this new this evolving approach at length, and I strongly recommend it.

The most interesting part about this piece may be the most basic. His definition of a ‘component’, the building blocks that comprise a microservices architecture, is “a unit of software that is independently replaceable and upgradeable.” Why is this so interesting? Because in my experience, most enterprise software systems do not think in units this small. In fact, many cannot think this small. Which is why so many are behind the curve in so many ways.