Skip to main content

Posts

Showing posts from 2013

Follow Through

As a young kid growing up in a small town, one of the very few things to do was join a bowling league.  My father, who has been bowling his entire life, used to coach me about the importance of following through your shot.  In a nutshell, the idea is that you aren't finished once you let go of the bowling ball and it's the act of continuing with the swing of your arm that increases the consistency of the shot and ultimately the score of your game. Professionally, the same is true.  Recently, I met the EVP of Corporate Strategy for CA Technologies, Jacob Lamm, for the first time in an executive briefing for one of our customers.  I introduced myself, and we chatted briefly.  In essence, I let go of the proverbial bowling ball.  And, following my father's advice, I sent him an email the moment he finished speaking and left the room.  In that email I described how I had been recommended by another executive for a position in his organization recently and, if he had a few m

The Reign of Mayer

This is a short entry, written simply because I feel a need to document this beyond the 140 character limit on Twitter. Marissa Mayer is great at being a reactionary leader.  She's stirred things up a bit, to be sure, but the vast majority of her work has revolved around correcting problems at Yahoo.  I am fairly certain you'll arrive at a similar conclusion after reading the very detailed and in depth history about her that was published by Business Insider a few weeks ago.  Immediately after reading that, however, I wanted to author this but it slipped through the cracks.  This may have been to my benefit, though, given the brouhaha that has sprung up over the choice of a new company logo . Let's face it, folks:  this is a logo consisting of a five letter word followed by an exclamation point.  The most interesting thing about it is the color purple.  Why is so much attention being given to this when there isn't much difference between the proposed new logos and

Being a Good Leader

The Leader A few weeks ago, I came across an article that described the 7 top qualities of a C-level executive.  And while I found the article to be a good read, I also recognized that there are key differences between a C-level executive and a "normal" manager.  This got me to thinking about the qualities that make up a good leader in general. The archetype for this person is my father who used his lack of a High School education as motivation to push himself harder than anyone.  He did ultimately get his GED and an Associates Degree via correspondence courses, but it was his ascension to upper middle management during his 30 year career with the company now known as CenturyLink that I focused on.  His qualities as a leader earned him such admiration that his former staff - he retired over 10 years ago - still respect him today as though they were still working together.  Here are the things that I learned from him over the years of my life. Communication is the key to

Why Do Software Defects Exist? (Part 2)

(Originally published at www.servicevirtualization.com .) In Part 1 , I proposed that application release decisions are not actually time-based but are instead risk-based.  To summarize, when the Lines of Business demand a specific time to release (from project inception) the Project Lead considers the risk to the business of releasing the application at that time.  This is illustrated to the right. Application Development Constraints Let's take a quick look at the "risks to the risk."  These are also known as constraints of the application development process.  I'll start by describing them as they are defined in the book Reality is Overrated (link goes to Amazon). Incomplete Development refers to the fact that software that a developer requires to validate their own code production is unavailable, requiring that developer to stub downstream systems.  The net result is that testing coverage early on is very sparse and puts the onus on the Quality Assuranc

Why Do Software Defects Exist? (Part 1)

(Originally published at www.servicevirtualization.com .) After my recent webinar (entitled Agile is Dead , replay is here , registration required but is free) I was having a follow up discussion with someone about it when the discussion turned to the nuances between what Agile actually promised and what people perceived it was supposed to deliver.  From my perspective, the simplest explanation is that Agile promised to help ensure that business requirements were being met while people thought it meant that applications would be produced with far fewer defects.  In the webinar, I described how Agile, if anything, increased the total number of defects due to its attempt to be more adjustable to the needs of the business mid-implementation. The question was then asked:  are software defects inevitable?  If not then why do they exist?  We're not talking about an insignificant problem.  As I've often quoted, NIST produced a study in 2002 that illustrated a cost multiple of 30 t

Software Release Management - A Problem Overlooked (Part 2)

In part 1 I expounded on the size of the problem surrounding software release.  We saw how the problem is bigger than I suspect many people realize by enumerating statistics published by IDC and Forrester.  Finally, I promised to describe how CA LISA Release Automation alleviates this problem. When I was a child, one of my favorite movies was The Wizard of Oz .  In one defining scene, Dorothy and her three companions enter the "throne room" where the Wizard agreed to meet them.  As they were talking to this giant, floating head, Toto discovered the curtain behind which the real "wizard" was operating this contraption. "Pay no attention to that man behind the curtain!" was the admonishment of the floating head. My question, and the relevance to software release, is:  what if it were not the "wizard" behind the curtain but was instead Glinda, the good witch?  What if it were a gaggle of the flying monkeys?  What if it was not any characte

Software Release Management - A Problem Overlooked (Part 1)

(Originally published by me on www.servicevirtualization.com ) This is the first of two parts discussing the problem of software release management and how automation can be properly used to alleviate these problems.   ITIL has Release Management. There are also Six Sigma and CMM. These are all process-oriented "libraries" that deal with the development and release of tangible products or business services.  Yet ask any application development professional if any of these deal with the actual problems of software release and they will unanimously answer "no." After CA Technologies announced that it had acquired Nolio , the leader in software release automation, I started taking a closer look at the actual problem that Nolio addresses.  And what I found is this: current literature on software release addresses the process-related problems but none has yet discussed how to address the realities of the actual movement of software from one environmen

Who are you?

I'm writing this from the lobby of a Hilton hotel in Toronto where I have been staying while I conducted meetings with a prominent Canadian bank.  Last night after a 13 hour day, I met a most amazing individual in the hotel bar.  The CEO of a successful consulting firm, his area of specialty is in the psychology of human behavior especially within the confines of a corporate setting. After a night's worth of very interesting, intellectual, and "i"ntertaining discussion with him and the others who were sitting at the bar with us I had the opportunity to speak with him one on one about my personal career ambitions.  During this he asked me a seemingly simple question:  "who are you?" I was taken aback.  "Who am I?" I thought.  "I'm Larry." "I'm a technologist whose name is on the cover of two programming books." "I'm a musician."  I finally answered that I am a "business strategist" but that ans

Why Agile and Test Driven Development (Part 3)

(Originally published by me on www.servicevirtualization.com ) Complexity yields defects In part 2 , we examined why SCRUM and TDD exhibit problems when measured from the perspective of the number of defects that they both yield. Before we can begin to understand why Service Virtualization helps address both of these reasons, it's worth elaborating on statements made in part 2. You'll recall the equation to the right, presented last time. c represents the degree of complexity, which has a direct correlation to the amount of code that must be written to meet the business requirements that yielded the complexity to begin with. Because t is fixed and c continues to trend upward (over several releases) then the number of defects will also increase over time. Therefore, t is the primary constraint around which everything else revolves. Expected number of defects In SCRUM , an increase in the complexity of an individual sprint or the total application expressed as

Why Agile and Test Driven Development (Part 2)

Classic physics... (Originally published by me on www.servicevirtualization.com ) In part 1 , we briefly examined the reasons why application development is challenged: namely, architectures have to be more complex to address the similarly more complex needs of the business.  We also briefly looked at the primary goals of Agile (SCRUM, specifically) and Test Driven Development (TDD) with the promise of further scrutiny to see why, although they take steps in the right direction toward better management of this complexity, they still fall short. The impact of increased application complexity is that there is an increased rate of change in all of the cogs and wheels that will (hopefully) mesh together to produce the final result expected by the business.  Over the same amount of time, this increased rate of change will yield more points where failure can occur.  And given the same distribution of probabilities, this will ultimately yield a greater number of defects. This bec

Why Agile and Test Driven Development (Part 1)

(Originally published by me on www.servicevirtualization.com ) Because I work closely with application development professionals on an on-going basis, I am fairly in tune with the happenings of that profession.  (It doesn’t hurt that I, too, was in an application development related role for 18 years.)  So when I heard more and more people extol the virtues of Test Driven Development (TDD) I wanted to look into it myself to see what the hullabaloo was all about. Application code is written to fulfill the requirements outlined by the Line of Business.  Taken as a whole, the result is an entire application that provides a business service, ultimately allowing an organization to either add new revenue streams or expand the capacity of existing ones. Architectural complexity increases with time The problem that often occurs is that “this isn’t your father’s application development job” anymore.  The need to remain competitive in the marketplace often adds the requireme

Wake Me Up

Last week, I was driving to and from various meetings with the business news on the radio when I heard the story that Facebook had some secret "thing" to announce to the media.  Perhaps I'm jaded but I immediately recognized this as an attempt to emulate the mastery that Steve Jobs had regarding his relationship with the media, so I was curious but thought little more than that. As you all know, the announcement really wasn't that exciting after all.  The concept behind Friend Search (not the official name, but one that sounds better than the official name: Graph Search ) is a decent one.  But the main problem I have with it is that most people aren't using Facebook for posting information that is worth searching through for answers to your problems.  David Hersh phrased it very nicely in my interview with him  in 2010: "Rather than continuing down the path of becoming a place to share meaningful content with 'real' friends, the focus on status u