Tag Archives: agile

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…


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.


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.


You Can’t Have it Both Ways: Offshoring Can’t Be Done via Outsourcing Companies

So the title of this blog most likely yields a giant “no kidding” response from my loyal readership, which is totally expected. A few of my teams work with an offshore consulting company. I won’t mention them by name, but I will say that they are big enough and global enough that most people in and out of the tech circle know who they are. Like most offshore companies they have their marketing propaganda that breaks down their value by industry vertical, area of specialization and global presence. They gloat about their amazing “Centers of Excellence” which differentiate themselves from their competitors. News flash…nearly every global consulting firm touts a Center of Excellence, which is code for “Sometimes we show customers a room with computers, monitors and white boards. This room is where all of the magic and innovation of INSERT MAJOR SKILL HERE happens.” Of course we all know that these CoE’s are just marketing fronts that really don’t exist.


Today I read an email from one of our contacts of this offshore service provider informing me of not one, but two team members who are “moving on to greener pastures”. This has been a theme for us now for roughly two years. Back when the economy was tanking in 2007/2008 we agreed to expand our investment in this firm. We made it clear that we were not outsourcing an entire responsibility, but rather extending our team through third-party team members overseas. The service provider wanted our business and made it clear that they would be able to help us find and retain talent. We agreed that we would do our part to invest in the skill set and agree to incrementally increase compensation. If at any point we were at risk of losing a team member, the 3rd party would do its part to shadow resources and seamlessly replace the team member who left via attrition.

Well as I said, the last two years haven’t been anything like the first four years. We have had more folks come in and out of the team that in the previous four years combined. In this particular part of the world, job jumping has returned to Silicon Valley like conditions in 1998/1999. We are lucky if we see a teammate come on-board for 8 months without either the threat of leaving or actually picking up and leaving. For a while I thought it was us that was the problem. I thought it was our work. I thought it was compensation issues. I thought it was quality of work life balance. For the most part I know that we do our part to address what we can control: the type of work, conditions of work and the opportunities for learning. We have little control over compensation, though we push our 3rd party service provider to address promotions and role leveling on a frequent enough basis that I am confident we influence each team members position and standing in their organization.

Don’t get me wrong…we have had issues ourselves. Forces above me have influenced contract pricing. We have fought rate increases and expenses. The folks on our business side definitely see the relationship as pure outsourcing (professional services) and not offshoring. They are right to do so as this 3rd party company deals with all of the headaches that I and my company don’t have to deal with these headaches.


The lesson here is that you can’t have it both ways. You really can’t use an outsourcing company to act as your offshore team, no matter how each of you spin it to the other. As the recipient of the service, you have to maintain a vested financial interest in your offshore team. You have to be able to directly influence the culture of the organization and not just the team. You have to be able to influence the quality of work/life balance and conditions of work. While controlling the type of work and norms of the team is important, it’s not the same unless you can also influence the organization. Probably the most important point is that your own organization has to view your team members who reside offshore as colleagues and teammates of the company. Just because they live in an another country with a different economic system doesn’t mean they should be inclined to a constant pay rate and salary.