18 posts tagged with "sdlc"

Hypothesis: at the beginning of their careers (and perhaps well into them), most software developers think written/verbal language skills are of little importance to their field. To the contrary: as with most science and engineering fields, where language arts and communications classes are seen as secondary at best, the truth is that communication skills are critical to success. Being "coherent" means that one is able to express himself in clear terms, logically and consistently. This ability is essential in both code and "regular" language.

A co-worker overheard the comment that "agile [software development] is not always a good fit for introverts," or something along those lines, while listening to a webinar on agile testing. On the surface, it is hard to deny that claim. Right there in the Agile Manifesto we have two obvious yellow or even red flags:

• Individuals and interactions, and
• Customer collaboration

Now jumping over to the Principles, we find two more orange flags:

• Business people and developers must work together daily throughout the project.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Sometimes you need to go back to the basics - including basic technology. In this case, I mean sticky notes. Yes, they are a remarkable form of technology. I like doing everything the digital way. I abhor using paper when not necessary, because of the waste factor. Although I love the idea of note cards for user story development, I've been thankful that they are impractical for my development team. But, I think it is time to heed good advice.

A friend just wrote to me, asking about agile. He's been seeing software job posting with the vague request/promise of "agile" in them, wondering what the big deal is. Initial reaction: if no specific methodology or agile principle is cited, then at worst they are glomming on to pop culture, at best they want to make sure you can

1. handle changing requirements,
2. deliver prototypes and/or working code frequently,
3. take an iterative approach to documentation, coding, and testing.

"Being agile" means both that you aren't going to freak out at the lack of a locked-down, step-by-step waterfall process, and that you aren't going to go cowboy and give the client a product at the last minute, with no conversations or demonstrations between the initial requirements "gathering" and delivery.

Stephen's first law of diagnosing problems in production should have been: make sure you actually know the scope of the problem. We have a process that checks for duplicates in an inbound file. Records marked as duplicates are not moved into production. A refinement of the process was installed this week. All the sudden, e-mails showed that thousands of records were being marked as duplicates. I came over to help investigate, and found people looking at code, trying to figure out what was going on, because they knew without doubt that these records were not in fact duplicates.

But we needed to step back and ask what is the scope of the problem? We looked at the e-mail with the duplicates, picked a name or two from the list, and looked in the original input files and confirmed that they were not in the files. So how/why were they reported? But then let's set that aside, and ask: did all of today's records make it into production? If yes, then we have a problem but not a crisis. The answer was yes: we could see a 1-1 match between inbound file and outbound production data. Therefore, we have a minor reporting problem, but the core of the system was working just fine. Panic averted.

So what was the cause? A staging table that had not been truncated after a previous file was processed. All those records were being reported as duplicates.

Stephen's first law of diagnosing problems in production: try to replicate in test. (Assumptions: you have a test environment, you use it regularly, and it is reasonably close to production). Sometimes you just can't replicate the problem — for instance, it might be due to an oddity in a customer data file that you're not allowed to run outside of production. In those cases, see if you can use a proxy. For instance, try copying the file and masking the sensitive data, then running it in the test environment (of course, the masking process might cover up the error that is causing all the problems).

Production needs to stay clean, and as developers we need to keep our hands out of it as much as possible. This is particularly true in a highly secure environment with strong separation of duties, wherein you might have to drag a sys admin into the picture just to get to obscure log files, for instance. Replicate the issue, solve it, document it, and make sure everyone else in the company is able to share in the lessons learned.

I've been using AccuRev, including AccuBridge integration in Visual Studio, for close on two years now. And I like it. I don't know anything about the licensing fees, but for the enterprise that is interested in spending some money, it is certainly a good option. So, for anyone considering using AccuRev for source code control, and who happens to stumble across this site, here are a few points to consider:

Postscript November 2020: from the days in which I was not allowed to practice "agile"...

You've written requirements. You've created a detailed use cases, and unit tests, and reviewed all three. Code is delivered, passes system testing, moves on to UAT. Whoa, holdup there fella, where's the data validation that prevents the user from doing X? Its right there in the requirements. What happened? Not only was it missed in the unit testing (and possibly use cases), but it was missed in the review process as well.