Thanksgiving Dinner and Software Releases

ThanksgivingThere are hundreds of ways to cook a turkey; every year it amazes me that folks just keep trying new things: In a bag, upside down, standing up, deep fried, rotisserie, stuffing in, stuffing out, smoked, barbequed, etc… The possibilities are only limited by your own creativity. In the end, the consumers of the holiday bird don’t really care how it arrived on the table, they just want it to taste good … am I right? The cook bears the burden of selecting a cooking strategy, leaving his or her reputation on the line each Thanksgiving holiday.    

This reminds me of the endless options for writing software. Should we use C# or Java? What type of interface, what methodology, what standards are we going to follow? In the end, the consumers of your products don’t care how you got to a release; they just want it to work. The developer of the software bears the risk and puts his or her reputation on the line with each release. Case and point: Apple’s most recent iOS 8.0, 8.1 and 8.1.1 releases. All of a sudden flawed software releases impact a company’s stock price, as demonstrated by Apple’s stock price dropping once the word got out about the buggy release. 

But the metaphor doesn’t end there. Thanksgiving dinner really is a lot like development.

The Requirements Phase:

The email goes out (at least a month in advance) to all family and friends asking them questions that you need the answers to in order to prepare dinner:

  • How many people are coming to dinner?
  • Are there any food allergies?
  • What does everyone want (besides turkey)?

These details determine the size and scope of the meal … sound familiar to planning a software release? 

The Design Phase:

Once the requirements have been gathered, the cook (and helpers) begin to design the meal around everyone’s cooking capabilities, taking into consideration their strengths and weaknesses. Another email then goes out detailing the requirements and asking for folks to sign up for cooking items they feel are their strengths. For example, my wife’s grandmother (Grandma “B”) always made an outrageous stuffing and roasted Kielbasa from the local Polish butcher. My mother-in-law makes peach cream cheese Jello that is nothing less than spectacular. And we always consider “Uncle Sid,” who has a refined palate and perhaps is our test case that we build our meal around. For those following Agile development, this process may sound strangely familiar.

The Coding (Cooking) Phase:

With Uncle Sid in mind, everyone begins cooking his or her part of the meal. If cooking on Thanksgiving, you have real-time access to Uncle Sid’s taste buds and iterate your dish in stages, gaining his approval before integrating your dish in with the rest of the meal. Sounds a lot like Test-Driven Development and scrum …

The Integration (Staging & Setting the Table) Phase: 

Everyone has come together in the kitchen and placed their dishes on the table, ready to go. Now there is just one final test to make sure everything is ready: Verify nothing on the list is missing (and then my mother-in-law snaps a photo of the dinner table because she wants to submit it to Better Homes & Gardens or send it to Martha Stewart herself). Every year there are some tears and hugs, and the hungry men in the family roll their eyes saying, “Enough already, let’s eat!” This is, of course, similar to the executives in your board room rolling their eyes saying, “Enough testing already, release it!”

The Deployment (Let the Feast Begin) Phase:

Dark or white meat, breast or thigh, stuffing or green bean casserole? Here comes the onslaught of family members filling up their dishes, consuming what has been prepared. This is where the rubber meets the road. Our product (Thanksgiving dinner) has been released and we wait anxiously for feedback. Software in today’s environment is no different. With millions of downloads moments after a release, the feedback can be instantaneous. 

The Market’s Feedback:

After a month’s worth of preparation and a lot of hard work (and perhaps some fighting), the dinner is over in 20 minutes. Based on feedback, (which caused Apple’s stock to take a hit after a bad release), some people may not be getting the pre-Thanksgiving email next year to contribute. It’s a harsh world, be it software or holiday dinners, but we do what it takes to make our end customers happy. 

Thanks for reading.  I hope I made you laugh. 

From my family to yours, we hope you have a wonderful and safe Thanksgiving holiday! 

Rob Cross
PSC Vice President, DCG Sales

Written by Rob Cross at 05:00
Categories :

Drinking the Agile Movement Kool-Aid

Rob CrossI recently had the pleasure of attending two single-day conferences focused on the Agile development methodology, Agile Philly and Agile D.C. I have been in the software industry the majority of my 20-year career and these conferences reminded me a lot of various professional experiences I’ve had over the years where I was selling a paradigm shift or disruptive change countering the usual modus operandi. 

 In general, the recipe for change for these shifts tends to include:

  • Tremendous Passion [You embody and live what you preach]
  • Unlimited High Energy [As if you had an I.V. drip of caffeine 24x7]
  • Junkyard Dog Tenacity [Where failure = valuable feedback and another opportunity to iterate success]
  • Infectious Enthusiasm [“Why is this dude always so happy and excited about this?”]
  • Unwavering Faith [When everyone else looks at you as if you’re crazy, yet you still believe you are on the right path]
  • A Dash of Luck  [There needs to be a little Irish in all of us]

 In both conferences I attended, it was absolutely obvious which folks in attendance were Agile practitioners – they had all of the above ingredients. 

Zealot / “zeal·ot” - a person who is fanatical and uncompromising in pursuit of their religious, political, or other ideals. 

I definitely found myself in the company of Agile Zealots, and I use this term in a complimentary way. Just like Moses came down from the mountain with the Ten Commandments, the Agile methodology has its own manifesto with 12 commandments and a dedicated website to remind us all what those are.


These Agile conferences, which take place nationally, remind me of localized crusades into corporate America’s IT departments to evangelize and convert managers and developers into disciples. I think these types of conferences are fantastic! And just to be clear, during an open question-and-answer session, I asked, “Are there any particular circumstances or projects where Agile doesn’t make sense?” (Before asking the question I definitely made sure I was close to an exit with no obstructions!) The whole room turned to look at me, but the panel appreciated the question and did not proceed to stone me in the town square; instead, it provided an excellent answer with various scenarios where Agile may not make sense. Bravo!


Agile is an excellent methodology and everything about it makes logical sense. However, as we all know, change is not easy and adopting Agile requires lots of changes organizationally and, most important, culturally. This change includes thinking of your organization as horizontal rather than vertical, as well as putting into place an Agile workforce development plan, which requires management sponsorship. This is very hard and I certainly heard stories while attending these conferences of disasters and successes. All success stories had tremendous heartache and pain, but their businesses, products and customers are far better off having gone through the metamorphosis.   

Just like most transformational things in life, the process to obtain success is not a light switch and may take years to achieve. However, if the entire organization embraces the recipe for change above, then converting from the old to Agile will be a lot quicker and easier – but not without failures along the way. Those who believe in the Agile manifesto and succeed in its implementation will obtain a powerful weapon to outmaneuver those who don’t. 

Of course, we're always here to help your organization effectively embrace Agile. Questions? Just ask!

Rob Cross
PSC Vice President, DCG Sales

Written by Rob Cross at 05:00
Categories :

Everything You Need to Know About Cyber Security You Can Learn From Your Plumber

Cash Is KingIs it me or do the headlines regarding compromised Point of Sale (POS) systems keep increasing in frequency? Let’s not kid ourselves, there have been some pretty big breaches …Target, Home Depot, Apple iCloud, and as of today, Jimmie John’s. To cyber attackers retail is the new banking sector!   

One of my best friends, Don, is a plumber and also a Captain in the Newark, New Jersey Fire Department. This guy works harder than anyone I know, and he’s probably one of the brightest guys I know. I always tease him that he should write a book called “Everything You Need to Know in Life You Can Learn from Your Plumber.” 

Interestingly, his solutions are always equated to how he would approach a technical problem from a plumber’s standpoint. 


A conversation with Don:

RC: “Did you hear about Home Depot getting breached by a cyber attack?”

Don: “I don’t understand what’s so difficult. Let me tell you what we do in plumbing. When a home owner doesn’t like what’s coming through the pipes, like the way the water looks or tastes, we test the water. Based on the water test results, we can put on layers of water treatment solutions to eliminate the threats, and then we can offer periodic testing. In fact, there are systems now that can do real-time monitoring of water quality and alert us when there is a change.” 

RC: “First it was Target, and now it’s Jimmie John’s … who’s next?”

Don: “In plumbing, water finds the path of least resistance, even the tiniest of holes in a pipe or structure will, over time, be found and exploited. Next thing you know, the hole gets bigger and things get ruined. There is always constant isometric pressure of water inside your home or business, and if it’s not contained properly, it will run amuck. This cyber problem sounds no different to me than what I deal with daily.” 

RC: “It’s scary stuff and every time I pull out my credit card to pay for something at a store, I think twice now.”

Don: “Rob, that’s why cash is king. Let those cyber idiots try to interfere with that transaction. If I don’t have the cash, guess what? I don’t buy it. Cards are for convenience, at the cost of security and trust, and it’s obvious to me that stores aren’t smarter than the bad guys, so why should I entrust them with access to my identity, which could lead to my money. The hackers always win.”   

Don: “I don’t understand why everyone doesn’t use PSC’s software security service. No plumber is allowed to self-inspect his or her own work. There are companies out there building pretty cool and important stuff with software, and I don’t understand why they trust themselves more than your company to offer an outside opinion. I don’t get it.”

RC: “It’s not an easy answer. Companies do what they feel is right, and oftentimes, that decision is tied to how it impacts revenue or competitiveness in the marketplace. Our customers realize the software security and quality battle is about data and not what technologies are used to identify the issues. Once they make this shift, it begins cascading through the culture of their company to be driven by data instead of opinions. I’m sure in your business there are homeowners who install their own under-the-sink filtration systems and then never check their water again or don’t change their filters regularly. They feel safe because they have purchased the “tool” that is supposed to catch the harmful things. Essentially, they are making their water potentially worse for their family. There will always be someone out there that you will never convince that you can do a better job and approach their water problem from a different perspective and provide better tasting water beyond their imagination. To them you’re just the plumber that only fixes pipes and not water quality problems. It’s no different in my business.”     

Don: “Hm … but my customers aren’t building things that could potentially kill someone, cause the market to crash or cause damage to their brand in the market. You won’t find me shopping at Home Depot anymore.” 

Don makes a valid point, right? This, of course, is why I have been urging him to write a book – believe me, his brilliance doesn’t stop at the current state of cyber security in retail. 


I don’t know if Apply Pay will save the day or Bitcoin or Zerocash. What I do know is that companies need to put aside more of their budgets to address cyber security on an ongoing basis. An unbiased opinion can provide valuable information that could make or break the future of your brand and the loyalty of your customers.


Rob Cross
PSC Vice President, DCG Sales

Written by Rob Cross at 05:00

Big Fish Eating the Little Fish: Mergers & Acquisition Indigestion

Mergers And AcquisitionsAccording to CNBC, this year is very hot and active for Mergers & Acquisitions. I would agree with that assessment, as I have been in many meetings and conversations with clients regarding their M&A strategies, more so this year than in years prior. This might lead you to ask, “Why would a software analytics company be talking M&A with their clients?” Great question! 

What most of our clients realize too late in the M&A process is their lack of understanding and awareness of risks lying deep within the software assets and processes of the company they are acquiring. M&A activity can cause major heartburn and indigestion for the technology executives tasked with figuring out how to assimilate outside technology and organizations into their own. Some of the basic questions that come up during such meetings are:

  1. How much of the software was organically developed by the acquired company?
  2. What open source and third party products are hard wired into the software?
  3. What intellectual property rights are protected or unprotected in the software?
  4. What type of additional exposure to cyber threats are being added to our system?
  5. What software process does this team follow and how does that integrate into our DEVOPS?
  6. Who are the domain experts on this software and how do we lock them down into a contract?


The good news is that for each of the above, there exists a solution/approach to mitigate the risk. For example, “How much of the software was organically developed by the acquired company?” Well, most acquirers have no idea regarding the composition of the software being acquired. They have little-to-no knowledge as to how much of it is organic versus open source versus commercial off-the-shelf. But, there are technologies that will decompose a software system and analyze all of its parts, indexing what was organically developed and what wasn’t. In addition, these technologies will invoke sophisticated pattern matching algorithms to identify whole parts and fragments of software used from the open source market, alerting you if there is a copyright issue or if there are known security risks with this piece of code.

In one particular case, we had a client who neglected any of this due diligence upfront and found out post-transaction that they were exposed to massive copyright liabilities due to the software not properly documenting use of open source and third party products.

Investigating these issues before they become real problems can alleviate a lot of costly pain and frustration.


More and more, our lives are driven by software-intensive systems. Traditional hardware companies are trying to pivot to software-driven solution companies in order to increase their margins and differentiate themselves in a highly commoditized marketplace. A great example of this is when I recently had to replace my air conditioning units at my house. When the salesman showed up to discuss what types of new units I wanted installed, his comment on why I should choose one superior brand over the others was the software embedded in the superior brand’s units, allowing me to save more money and have a more comfortable climate-controlled home! This was a HVAC guy telling me that software is the reason why I should pay another $4,000 per unit! Really!? It’s a great illustration of how one company in a highly commoditized market is able to achieve a higher price point and superior brand recognition by emphasizing their software as the solution and not just the physical unit. Bravo!


What has always been interesting to us, knowing that software is truly eating the world, is that acquirers are quickly becoming more aware as to the risks that software represents within an M&A transaction. What we have found during M&A transactions is that, traditionally, the acquirer audits everything except the code. However, with cyber threats in abundance and software becoming a dominant strategy for brand dominance, the “smart money” leaves no software stone unturned before the ink is dry, truly understanding the value and risks of the transaction down to the bits and bytes.

If you’re curious about how we can help, a great place to start is our case study, “DCG Supports Acquisition Due Diligence Team in Managing Technology Risks for Transaction Success,” which is available on our website. Of course, if you have specific questions, feel free to leave a comment or shoot me an email!

Rob Cross
PSC Vice President, DCG Sales

Written by Rob Cross at 05:00
Categories :

The 500lb Marshmallow!

Never give up and keep swinging!

MarshmallowI often describe challenges that seem to only move an inch at a time despite a ton of effort as, “Swinging at the 500 pound marshmallow!” I have found that over my career in the software industry, many problems in our customers’ environments could also be described as a 500 pound marshmallow. But, as an independent software assurance company, proServices often has both the perspective and objectivity to recognize and assess these challenges more frequently than our customers because they’re too exhausted to see what’s coming. 

These challenges range across the software lifecycle and have been around since the ENIAC (pictured below).

ENIAC Computer

Some notable challenges from the C-Suite of our customers include:

  • “Why are my projects always late?”
  • “Why are my projects always over budget?”
  • “We always find out about our defects too late and from our customers first!”
  • “What process should we be following?”
  • “How do I get more out of our testing efforts?”
  • “We need to do a better job of estimating cost, schedule and functionality upfront.”
  • “I wish we had more proactive visibility into our technical debt.”

Fantastic concerns – and ones you would expect from the C-suite. These challenges have not changed much over the years, but the technology underneath has changed dramatically, from architectures, languages, and hardware to data models, the approaches available to tackle these challenges continue to improve.

So, instead of utilizing the same old series of punches at these marshmallows, why not try something new to see if we can move it a foot instead of an inch? 

Design & Estimation

For starters, you need to put a proper estimation process in place, at the front of the process, as well as a mechanism to measure the result on the backend of the process. This ensures that you’re producing the functionality for the projected cost and schedule. Most of you would probably agree that you design quality into the system, starting at the beginning of the process. I am not an expert in software architectures, but I do understand the importance of having a well thought out strategy that incorporates growth and flexibility to accommodate constant change. Addressing these important items upfront will help mitigate substantial defects later in the lifecycle. One of the biggest benefits of having a solid estimation capability is being able to gauge how well tuned your engine (or process) is for production capacity.  This enables vital information for organizations to continually improve their process by providing constant feedback.  There are companies that offer consultants in both of these areas, as well as a number of products on the market for you to do it yourself, perhaps with some outside expert guidance. Done.        

Build it Right the First Time

How? By implementing an Agile process that includes a continuous integration DEVOPS. Once that’s in place, you should have a system that provides software risk analytic reports profiling quality, security and performance for every build. By providing early and iterative transparency into technical debt, you will be able to significantly mitigate and reduce the rate of defect injections into your software during the execution phase. Leveraging technology platforms to collect important data; correlating it to risks important for your organization to understand and proactively mitigate; and finally, having the collaborative mechanism to socialize this data across the organization from executives to engineers.  There are also companies that offer this as a service and provide platforms that integrate these technologies into the DEVOPS environment. Done.

Testing has a Seat at the Table

Now, your testing team has to be integrated with your development team by driving a test-driven development process from the beginning. Some key metrics, such as functional and performance testing success/failure ratios, should be mapped into your dashboards, as well test coverage metrics to measure the effectiveness of your testing efforts. Then, you should use automation integrated into your DEVOPS and CI environment to streamline the operations. By designing tests upfront and setting aggressive performance targets, you will significantly reduce the defect injection rates at this phase of the lifecycle. Again, there are companies that offer this as a service and technologies to make this happen. Done.

What’s my point? One of the top five complaints we have heard over the years from the C-suite involves finding defects too late in the process. Yet, we continue to swing at the 500 pound marshmallow with the same strategies, expecting different results and finding only frustration. Everything I’ve outlined above can be tackled internally by most companies, but sometimes the solution requires an objective third-party who can analyze the problem and then implement the solution on your behalf. Maybe moving the 500 pound marshmallow requires a new perspective and the help of someone else, but in the end, you need to keep swinging at these challenges to keep moving forward.

Keep Swinging! 


Rob Cross
PSC Vice President





Written by Rob Cross at 05:00

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!