Monthly Archives: April 2014

Continuous Delivery…Continuous Integration…Continuous Deployment…How About Continuous Measurement?

I spend a lot of my free time these days mentoring startups in the Washington, DC and Baltimore, Maryland markets. I mentor a few CEO’s, who are building software for the first time, as well as a few folks in the roles of VP of Engineering or Director of Development. It’s fun and exciting in so many ways. I feel connected to a lot of these startups and personally feel a lot of satisfaction mentoring some really great people, who are willing to put it all out there for the sake of fulfilling an entrepreneurial spirit.

I’m not just partial to startups. I enjoy collaborating with peers and colleagues that work at more tenured companies. I think it’s important to get alternative perspectives and different outlooks on various subjects such as engineering, organizational management, leadership, quality, etc…

http://www.miraclegroup.com/images/easyblog_images/205/lean.gif

For about four years or so there’s been a common theme amongst many of my peers and the folks I mentor. Everyone wants to be agile. They also want to be lean. There’s a common misconception that agile = lean. Yikes! I’ve also noticed that a lot of them want to follow the principals of Continuous Delivery. Many assume that Continuous Delivery also means Continuous Deployment. The two are related, but they are not one and one the same. Many of them miss that Continuous Integration is development oriented while Continuous Delivery focuses on bridging the gap between Development and Operations (aka…the DevOps Movement). Note: DevOps is a movement people…not a person or job.

The missing piece…and I say this with the most sincere tongue by the way…is that there still remains this *HUGE* gap with regards to “What Happens to Software In Production?”. My observation is that the DevOps movement and the desire for being Continuous prompted a lot of developers and operations folks to automate their code for deployment. The deployments themselves have become more sophisticated in terms of the packaging and bundling of code, auto-scaling, self-destructing resiliency tools, route-based monitoring, graphing systems galore, automated paging systems that make you extra-strong cappuccinos, etc…Snarky Comment: Developers and Operation Engineers can’t be satisfied with deploying an APM and/or RUM tool and calling it a day.

gadget  monkey

Continuous Measurement is really what I’m getting at. It’s not just the 250k metrics that Etsy collects, although that’s impressive or maybe a little obsessive to say the least. I would define Continuous Measurement as the process of collecting, analyzing, costing, quantifying and creating action from measurable data points. The consumers of this data have to be more than just Operations folks. Developers, architects, designers and product managers all need to consume this data. They *need* to do something with it. The data needs to be actionable and the consumer needs to be responsive to the data and thoughtful going forward for next generation or future designs.

In the state of Web Operations today, companies like Etsy or Netflix make a tremendous amount of meaning from the data they collect. The data drives their infrastructure and operations. Their environments are more elastic…more resilient and most of all scalable. I would ask some follow-up questions. For example, how efficient is the code? Do they measure the Cost of Compute? (aka: the cost to operate and manage executing code)

Most companies don’t think about the Cost of Compute. With the rise of metered computing, it’s amazing to abstract the lost economic potential and the implied costs because of inefficient code. Continuous Measurement should strive to balance that lost economic opportunity (aka…less profit). Compute should be measured as best as can be from a service, feature and even at a patch set level.

A lot of software companies measure the Cost to Build.  Some companies measure the Cost to Maintain. Even less measure the Cost to Compute. Every now and again you see emphasis placed on Cost to Recover. Wouldn’t it be a more complete story with regards to Profit if one was able to combine the Cost to Build with the Cost to Maintain and the Cost to Compute?

Maybe the software community worries about the wrong things. Rather than being focused on speed/delivery of code and features, maybe there should be greater emphasis placed on efficiency of code and effectiveness of features. Companies like Tesla restrict their volume so that each part and component can be guaranteed. Companies like Nordstrom’s and the Four Seasons are very focused on profit margins, but at the same time they value brand loyalty in favor. I used to think that of Apple, but it’s painfully obvious that market domination and profitability have gotten in the way of reliable craftsmanship. I love my Mac and IPhone, but I wish they didn’t have so many issues.

http://www.toonpool.com/cartoons/buy%20magic%20beans_53582

I have no magic beans or a formula for success per se. I would argue that if additional emphasis was placed on Continuous Measurement, many software organizations would have completely different outcomes in their never-ending quest to achieve Continuos Delivery, Continuous Integration and Continuous Deployment. It just takes a little bit of foresight to consider the notion that Continuous Measurement is equally important.

Advertisements

What Ever Happened to Software Patterns and Anti-Patterns

Thirteen years have passed since I first read Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software, which if you know me well I consider it my bible of Software Performance Engineering. Note, I’m not a religious guy so the fact that I referenced the bible is saying a lot. I still keep a copy of it about 5 feet from my desk. I lend it out at least 3 or 4 times a year to members of my team still to this day. It’s a book that clearly maintained its luster. I can’t call-out anything in the book that doesn’t apply to today’s computer scientists. 

Image               Image

My big takeaway from the book and the teachings’ of Smith and Williams is the notion of Software Performance Anti-Patterns. Earlier in my career and my studies I was intimate in my learnings about Software Patterns. I read the Gang of Four’s classic Design Patterns which was published in the mid-1990’s and in awesome fashion is still relevant today. I have a copy of that book sitting next to my copy of Performance Solutions. I wonder if today’s CS graduates are even reading either of these books as solid references. It’s like a journalist or English major making it through undergraduate studies without reading Strunk and White’s Elements of Style. Is it possible to graduate without reading these books?

Image

As a young engineer and computer scientist I focused persistently on software performance, I lived and breathed patterns and anti-patterns. I used them for meaning as well as guidance in helping my fellow developers learn from simple coding mistakes that in the early days of Java were easily exposed. Early Java code in the days of Java 1.3 and 1.4 was wasteful. Heck, there’s still a lot of Java code today that’s wasteful as well. By wasteful I am referring to poor memory management and wasteful requests to name a few. Simple anti-patterns such as wide loads or tall loads were common. There was blatant disregard for understanding the lifecycle of data, how data was accessed, whether the data was ephemeral or long-lived. There was too much inter-communication transport between containers and relational data stores. Not that I’m trying to equate every software pattern to memory management, data transport or advocating the use of caches to solve every problem. I’m just picking a few off the top of my head.

Image

So my goal of this post is not to sound like a curmudgeon. I’m too young to be old and crabby. I’m not a purist either. I’m more of a pragmatic engineer who likes to constantly ask questions. That’s the forensic side of my personality I guess. The question that’s on my mind these days is do the developers of today…specifically the developers who are going hard after languages such as PHP, NodeJS and Ruby, think about software patterns and anti-patterns? Do we see an absence of thought around challenging our designs because our code can be quickly assembled via frameworks tied to these languages and others? Has Lean Thinking made developers more conscious of code productivity versus code efficiency?

I’m sure I’m going to get lambasted by a few readers who are passionate about these modern web frameworks and the new stacks. That’s cool and fine. I personally am a big fan of these stacks and capabilities. Mainly because they make the development of software more accessible to everyone. That’s not my point in being interrogative about design patterns and anti-patterns. I guess I’m more curious about whether developers today are thinking about design patterns and are able to identify anti-patterns, or whether they are more focused on writing code faster and with less effort. Don’t forgot code that’s testable from the start.

That’s actually one of the greatest observations I’ve seen about today’s developers using these newer languages and frameworks. The are social coders that fork and pull all of the time. They are following more agile practices around TDD and BDD. They write their own automation. A lot of these developers take more accountability of the quality of their code than any other generation of developers that I’ve witnessed. Note I am young (38) and really have only worked with 2 or 3 generations of coders. A lot of these developers are focused on deployment of their code as well. They make use of the accessibility of systems through providers like Amazon, Rackspace, Azure, Google and Heroku. They leverage deployment tools like Capistrano or RunDeck. They write automation with configuration management frameworks like Chef, Puppet and Ansible. They love APM tools like New Relic or AppDynamics. All indications support the thesis that today’s more modern developers take more accountability of so many facets of development.

We should commend those developers for what they are doing. Greater consolidation of languages, frameworks and tools increases the likelihood or probability that the community of contributors to these technologies will give back. It also leaves open, which in my small sample size, the possibility of bliss or unawareness to good design, structure and scale. You have more developers today than in any time in the world. There are more outlets for developers for social coding, open source contributions, etc…Is it possible that a larger percentage of developer are really just coders, assembling software as a commodity? This is more passion and theory, than empirical analysis…

I did some unscientific research…aka lots of Google Searches…here’s my observations:

1. The few relevant postings I saw about software design patterns and anti-patterns were more scholarly. They were traditional research papers written by academia posted on ACM or IEEE. While I used to be a big ACM and IEEE reader back in the day, few of my contemporaries use it or refer to it. In fact, I haven’t read an ACM or IEEE article since after 2010, which is kind of sad.

2. A lot of blog posts and even slideshare presentations used anti-patterns in the software context about developer habits or bad behavior. This kind of annoyed me the most because there were some folks that run in the same circles that I run in. They weren’t talking about code design (good or bad), but rather behavior. 

3. The one community that anecdotally had the most entries around design patterns and anti-patterns was the Scala community. That made a lot of sense to me as every Scala developer I know was a hard-core Java developer who made a run at Ruby for a project or two and decided that Play was even cooler than Rails. 

4. The MVVM community big on backboneJS, angularJS, emberJS, etc…didn’t really write much about anything pattern or anti-pattern at all. There were blogs and presentations. Some were good…some were so so. Most were developer behavioral. Most were about code efficiency. There was this one blog about backboneJS that was ok. Nothing game changing…Nothing that would act like a slap in the face to developers to think about the efficiency of their design, ability to scale and the cost of compute.

That last phrase I guess is what blows my mind (ie: “cost of compute”). I got into the world of software performance and optimization at a time when compute was really expensive. We saw years of compute (CPU and Memory) become a commodity. If our code couldn’t scale, we would simply add more memory, more CPUs, more bare metal systems, more VMs, more storage, etc…The public cloud makes that access to more compute so simple…

The compute of 2014 and beyond is metered now or better yet again. It was metered back in the early days of timeshare computing. Today, I find myself getting out of the game of running private data centers or using colos. I buy less hardware and storage each year. My private data center footprint is the smallest it’s been in years. Not because of virtualization and consolidation, but rather because I’m moving more stuff outside to the public cloud.

Each month I look closely at that bill I get from Amazon and Rackspace. That meter is constantly running. Pennies add up and you don’t realize it until it’s late in the game. It turns out a lot of that waste is because my cost of compute (aka…the efficiency of our code) isn’t as great as it could be. We write a lot less code, but it’s not necessarily all that efficient.  

I’m hoping this blog starts a conversation, not a fight. The thing I see is that innovation in the software world is at an all-time high. We do have more developers than we have ever had in our lifetime. We have more languages and frameworks today than ever before. We have more choice…more variation…more outlets. At the same time, I can’t help but think about questions like:

  • Are we producing more coders than developers because we have a supply/demand problem?
  • Are the CS grads we are producing around the world bliss of solid architectural design?
  • Do developers focus less on good system design, sustainable, long-lasting architectures to be used for years or do they place more emphasis on quick applications?
  • Has the days of profiling become an ancient practice to be done by the few developers and avoided by coders?
  • Has the accessibility of cheap compute blinded our awareness of cost?

I probably could go on for longer…