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 requirement of being both incredibly agile (resulting in more aggressive / shorter release cycles) while at the same supporting the latest trends in technology as a business enabler. Currently, big data, cloud computing, mobile device support and “the Facebook effect” (meaning highly interactive applications taking great advantage of asynchronous processing to provide nearly instantaneous results) are the darlings of the industry but it could be anything.

As a result, the applications that are being demanded by the Lines of Business are increasing in their complexity. And that means the task of managing the resulting application quality has also become more complex. This spawned the Agile development movement, which ultimately evolved to TDD. Both of these were devised to manage the complexity so that the rate of change does not make the ability to validate the correctness of the result time- and cost-prohibitive.

For those of you who have not been exposed to TDD, the primary difference between Agile (we’ll use SCRUM here as the reference since that is arguably the most prevalent Agile methodology in use) and TDD is the following:

SCRUM defines success as the successful implementation of a set of features and functionality to be completed by the end of the next sprint, and the developers write code to meet those goals
TDD, however, defines success as the implementation of code that successfully addresses a set of (initially) failing tests that are developed in parallel by the developers

In part 2, we’ll take a look at why both of these are not the panacea that they were initially hailed as when they were gaining in popularity.

Finding Clarity in the Chaos of a Job Search

Job searches are humbling. They test your confidence, your patience, and your ability to stay motivated when things don’t move as quickly as you’d like. But they also teach you things about yourself that you might not have learned any other way. For me, the past few months have been a crash course in rediscovering what really matters: not just in a résumé, but in relationships, self-perception, and how we use technology to help tell our stories. Here are three lessons that stood out. Reach Out to Your Network (Long Before You Need It) Your network is a living thing. It requires upkeep, time, and attention, just like a flower garden. You can’t ignore it for years and expect it to bloom the moment you need it. Start planting early. Stay in touch with people whose paths you’ve crossed - colleagues, mentors, partners, even those you only worked with briefly. Drop a note once in a while. Comment on their posts. Share something that made you think of them. These small gestures are the sunl...

Time to Level Up!

With the recent news out of Salesforce and Oracle, it’s easy to understand why folks affected by layoffs might feel discouraged. Not only are they leaving companies they may have called home for years, but they’re also facing the daunting prospect of job hunting while headlines scream about “AI taking over human jobs.” Not long ago, another company I follow - let’s call it Acme - went through a similar round of layoffs. Two employees in particular (we’ll call them Jim and John) showed how mindset can make all the difference. Jim had been at Acme for over 20 years. He was reliable, steady, and well-liked, but not exactly the standout type. When he was laid off, he decided to take some time off before even thinking about his next move. After all, he had a severance package. Didn’t he deserve a break after two decades of hard work? John’s story was different. Though he hadn’t been at Acme as long, he’d built a strong reputation and had both technical and leadership skills. Instead of...

COSMIC Insights

Consider the following scenario: you're a mid-level manager and find out that a layoff is coming. You're about too lose one of your best direct reports, but you have no ability to influence the decision to lay them off. Oy! My head hurts! What do you do? Oftentimes, I find that people - when presented with situations where they feel compelled to act but have no ability to change the outcome - enter a state of mental lethargy. They don't know exactly what it is they should do but, "gosh darnit!", something has to be done. When they realize how helpless they actually are, they start lamenting about the situation, how they are backed into a corner, etc. In a very real sense, they go through the five stages of grief . I'd like to offer the following alternative way of approaching these and other situations: I call it the COSMIC method, not only because it sounds cool but also because I like science fiction (" Lisan al Gaib! "). COSMIC is an acronym...

A Businessman's View

Search This Blog