Taking software development on faith

TOPEKA, KANSAS, APRIL 1 – Speakers here at the Faith-Based Development Conference have demonstrated a software development methodology based on the concept that if you believe the code will work properly, it will work properly.

“All you have to do is believe, and we do this all the time,” said Ebenezer Scroom, CEO of Faith-Based Software Development Inc. (FBSDI), which sponsored the conference. “We turn the car key and believe that our engine will start… and it does. We push bread down into the toaster and believe that toast will pop out… and it does. We write thousand of lines of C# or Java, click the ‘Build’ button and believe the application will execute correctly the first time. In his heart of hearts, every developer believes this! The good news is that if you follow the principles of Faith-Based Development, your app will work the first time.”

Scroom cited anecdotal studies that demonstrate the power of Faith-Based Development to cut costs, shorten development cycles, improve software quality, and so on. “These results have been validated by industry analysts,” he said, “who were duly impressed when we hired them to author white papers and conduct webinars for FBSDI.”

There are four pillars of Faith-Based Development, explained Scroom, all of which can be easily implemented by tools sold by FBSDI. A project begins with Faith-Based Modeling, where architects use UML to document what Scroom calls “Faith Cases.”

Next, Faith-Based Coding relies on plug-in modules for Visual Studio Team System and Eclipse. “If you have faith that your syntax is right, then it’s going to be right,” he said.

The third phase is Faith-Based Testing. “This is perhaps the easiest part to learn.” Scroom said. “Developers are used to firing up their automated test suites, closing their eyes and praying. What we now know is that it’s the quality of the prayer, not the comprehensiveness of the test harness, that really matters.”

Finally, he said, it’s time for FBSDI’s Faith-Based Build and Deployment Services to bring together the final assemblies and push them out to the data center in one irrevocable operation.

“If you believe the software will be perfect the first time, there’s no reason to implement a phased rollout,” Scroom said. “If you have faith, you will succeed. If not… have I mentioned our professional services division?”

CLOUDBASIC opens computing paradigm to students, Mindy

DARTMOUTH, N.H., APRIL 1 — Hearkening back to the earliest days of computing education, a team of computer scientists have developed a special programming language to help students learn how to create mashups in the cloud. The language, CLOUDBASIC, was unveiled at Dartmouth College, home of the original version of BASIC.

“It’s been 47 years since John Kemeny and Thomas Kurtz showed off Dartmouth BASIC,” said Sara dePragma, a graduate student involved with the programming initiative as part of her Masters in Computer Education. “Heck, I wasn’t even born then. Come to think of it, neither were my parents. Sheesh!”

According to dePragma, the eight design principles of CLOUDBASIC are:

1. Be so easy that total losers like her roommate Mindy could use it.
2. Be a general-purpose programming language suitable to use as both a dessert topping and a floor wax.
3. Allow advanced features to be added for experts (which, duh, would make the language unusable by Mindy).
4. Be interactive using things called “dialog boxes.”
5. Provide clear and friendly error messages when a rogue program brings down the entire cloud environment.
6. Respond quickly for small programs, such as “Hello, Cloud.”
7. Not to require an understanding of the cloud’s hardware, unless the server is using an AMD processor.
8. Shield the user from the cloud, because the cloud is very big and ethereal.

Prof. Angus McMushroom, dePragma’s advisor, was quick to point out that the use of the GOTO statement within CLOUDBASIC was not his idea. “It’s not my idea,” he insisted. “I just know that nothing good’s going to come of it. I can just imagine that Ed Dijkstra’s turning in his grave. Just don’t blame me, okay?”

At the Dartmouth announcement, representatives of major cloud and industry players were present to pledge their support for the language:

• Microsoft released the first Community Technology Preview of CloudBasic#.NET for Windows Azure and the unannounced Visual Studio Team System Cloud Edition 2012.

• Sun announced that the Java Community Process would begin a JSR to develop with a language that’s similar to CloudBasic#.NET, except incompatible in a few subtle ways, and which would be implemented in NetBeans.

• The Eclipse Foundation is trying hard to come up with an acronym for their own CLOUDBASIC project, which it says will have OSGi extensions that will render it subtly incompatible with what Microsoft and Sun are doing.

• Apple has released iCLOUDBASIC, available in the iTunes App Store as a US$0.99 download.

• Google showed off the public beta of Google CLOUDBASIC Web Services, which are expected to remain in public beta for the next 20 years.

• Amazon.com invited SD Times readers to purchase the Kindle version of “CLOUDBASIC for Total Losers Like Mindy” at a 25% discount. Use the code MINDYISALOSER at checkout.

• The Free Software Foundation released an angry statement warning that it and the Software Freedom Law Center will sue any organization that doesn’t refer to the language as either GNU/CLOUDBASIC or as gcb.

“I’m so delighted to see everyone adopting CLOUDBASIC,” said Dartmouth’s dePragma. “Now, who’s up for helping me design its debugger for my Ph.D. dissertation? Mindy?”

This one's for you, Zephyr!

Letters! Letters from fans! They love me, as you can see in this e-mail that came in today. This is the best message that I've received this decade.

Hi,

We came across your "i.b. phoolen" blog and appreciate the informative content you have there.

We have just launched Zephyr which is a next generation Test Management System and wanted to introduce you to it by providing an exclusive look. Here's a live demo link – http://demo.yourzephyr.com – and there you'll be able to interact with the system anytime. We've loaded it with sample data to facilitate any product reviews. You'll find other assets (screenshots etc.) on the Media section of our main website – http://www.getzephyr.com.

Zephyr is a slick, feature rich and affordable Test Management System aimed at global SME, IT Departments and Testing Vendors. It brings a whole bunch of innovation in a space that has lacked it for the longest time. We'd like to draw your attention particularly to our customized Testing Desktops, real time Collaboration and Live Reporting via slick Dashboards as well as a host of Web 2.0 features.

We are test engineers ourselves and have designed and built Zephyr based on multiple years of real world experience. Your feedback or a mention on your blog would be very interesting to your readership while being a source of encouragement to us.

Thanks,
Sean Stewart
sean.stewart@getzephyr.com
http://www.getzephyr.com

The Software Tester’s Bill of Rights

Software testers are people too! Many of my best friends are software testers, and I can guarantee that they are people. In many countries, people have rights. Well, not everyone has rights. Airline travelers don’t have any rights, as we all know. Celebrities don’t have any rights. Neither do people who talk loudly on cell phones in restaurants or on the subway.

The reason why people talk loudly on cell phones is a design flaw, by the way. If the people who designed cell phones wanted to make friends, they’d program the phones to drop the call if the caller is being too noisy. Hey, rude people, mobile phones have sensitive microphones. You don’t have to shout!

Okay, we’ve established that airline travelers, celebrities and cell-phone abusers don’t have rights. What about the rest of us? We have rights, and that goes double for software testers. You know, testers take it in the shorts most of the time. The customer changed his mind after seeing the beta, and testers have to catch the variances. The architect messed up the caching algorithms? Testers have to account for nondeterministic behavior. The programmers spent too much time playing foosball? Test cycles get compressed. A line-of-business manager decided to release the software early? Test cycles get compressed. An end user found a bug? Testers get blamed for missing it.

Good people, it’s time we fight back with our very own Software Tester’s Bill of Rights. I know that you’re asking yourself, “What a brilliant idea. But who would write this Bill of Rights for us?” Fear not, gentle software tester. I.B. Phoolen is more than happy to draft this important document on your behalf. And now, without further ado, I present: The Software Tester’s Bill of Rights.

1. The Right to Own the Requirements

A tester’s job is to ensure that software meets requirements. Where do those requirements come from? Some from the customer. Some from the architect. There’s the problem.

Many of those requirements are obtuse, poorly written or plainly misguided. Those user stories — c’mon, folks. Don’t you have any imagination? Those performance and reliability metrics — you’ve got to be kidding, that throughput will never fly on a real-world network.

No wonder there are so many defects found by the test team, no wonder the overpaid programmers take so long to get the job done, no wonder the entire project is over budget.

Fortunately, we testers know better. We know what’s a good requirement, and what’s totally lame. Let us fine-tune the specs. Let us control the specs. If we disagree with a feature request, let us revise it or delete it.

If the test team owns the specs, we can guarantee that our tests will show that the application meets those specs on time, on budget, blah blah blah. Guess what? It’s not a bug, it’s a feature!

2. The Right to Kill the Project

That’s right. If the requirements are sufficiently moronic, or if we think the project is silly or necessary, we’re going to axe it. I.B. calls that “improving ROI.”

3. The Right to Choose Our Own Test Tools

Everyone talks about how developers are creative free spirits, who should be able to use the tool chain of their choice. If some programmers want to use Visual Studio or the IBM Software Platform, that’s fine with their managers. If Bob wants to run JBuilder, that’s fine too. If Sally wants to run Eclipse, nobody objects. If some show-offs eschew IDEs altogether to write the entire application with vi, lint, gcc and some duct tape, more power to them.

Meanwhile, C-level executive bozos want to standardize the quality assurance suites to embrace new flash-in-the-pan paradigms like “test automation” and “test driven development. They insist that testers use uniform tools and bug tracking applications, or — heaven help us — “ALM suites.”

Bullfeathers. Testers are just as creative as developers, as you can tell by reviewing my recent expense reports. We demand a generous budget so we can choose our own tools. As far as I’m concerned, every tester has an unalienable right to adopt the defect management system of his or her own choice, even if it’s Excel. If the CIO and VP of IT don’t like it, well, that’s their problem, bunky.

4. The Right to Employ Agile Methods

Preferably, those agile methods would be demonstrated by a perky aerobics instructor wearing a torn sweatshirt and leggings like Jennifer Beals in Flashdance.

5. The Right to Determine Release Schedules

I’ve had it up to here with test cycles being compressed due to boneheaded requirements, flawed architectures or nitwit coders who wouldn’t know an unchecked buffer if it bit them in the nose.

I don’t care if you’re rushing the product out to meet some contractual guarantee or the holiday shopping season. Under this Bill of Rights, any tester — any tester — can push back the release schedule at any time, with or without cause, and there ain’t nuthin’ you can do about it. If a line worker’s power to halt the production line improves the quality of Japanese cars, then by gum it works for software too.

6. The Right to Blame Microsoft for Everything

Self-evident.

7. The Right to Blame Open Source Software for Everything

Self-evident.

8. The Right to Redefine the IT Org Chart

In some organizations, development and test are peers. In others organizations, testers report into the development organization. Both of those models are flawed.

The only reason that companies hire architects and developers is to create applications for the test team to test.

Therefore, ipso facto, development is a subset of the test organization, and should be treated as such. That means that all developers work for the test organization. And, of course, all testers get paid more than developers, and get all the best parking spaces.

Take that, coding prima donnas. Who’s your daddy now?

9. The Right to Wear a Badge and Uniform

Heck, if we’re going to be the Quality Police, we might as well look the part. That’s especially important when doing Fuzz Testing.

10. The Right to a Whopping Pay Raise

If it’s good enough for politicians and CEOs, it’s good enough for software testers: We work hard, so we demand a bigger piece of the pie. Cash is good, but we’d like a generous serving of backdated stock options, too. Oh, while you’re up, could you grab my cell phone? I need to call Jennifer Beals. Thanks.

Retired software engineer I.B. Phoolen lives in Southern California, where he regularly frolics. He rarely updates his blog at ibphoolen.blogspot.com.

High-Tech Industry Consolidation Continues

SAN FRANCISCO, APRIL 1, 2018 – Tsunami waves of consolidation continue to break against the software industry, as MicroCiscoYahooOraclesoft announced a US$2.4 trillion takeover of IBMhpSAPemc. Meanwhile, Apple Telephone & Telegraph agreed to merge with GoogledellSUNokia in a deal worth $3.7 trillion.

“This is a fantastic day for consumers everywhere,” shouted Steve Ballmer, chairman of MicroCiscoYahooOraclesoft. “Ever since the last anti-trust restrictions were lifted from our company yesterday, we began looking for new ways to innovate and bring more choice to customers. This acquisition goes a long way toward bringing us closer to Bill’s dream of ‘information at your fingertips across the road ahead at the speed of thought,’ or as I like to say it, IAYFATRA@TSOT.”

While critics swiftly charged that the MicroCiscoYahooOraclesoft move is all about increasing its share of Internet-based advertising, comments from a pay-for-praise analyst hint at a bigger target: mainframe consolidation and positioning Big Iron as next-generation smart clients. Noting that current mainframes rival mobile phones in size, the ability to combine the technologies in new, exciting ways creates powerful synergies, said Ivan A. Suckup, director of The Suckup Group.

“Imagine a pocket-sized IBM mainframe running Microsoft operating systems and Oracle databases, combining HP’s consumer marketing prowess with SAP’s business back-end integration, EMC’s storage technology, Cisco’s connectivity and Yahoo’s leading-edge ad-delivery platform,” Suckup said. “If they can only solve the cooling problem, and get more than three milliseconds of battery life from the fuel cell, this will truly be the killer platform of the future.”

The Suckup Group recently placed MicroCiscoYahooOraclesoft into its Golden Sector of Industry Innovation & Leadership™. “They’re our best client,” gushed Suckup, “and they subscribe to every one of our overpriced services. However, that in no way is related to our upgrading our honest, impartial recommendation to ‘Buy all their stock that you can afford, even if you have to clean out your kid’s college fund and take out another mortgage on your house.’ ”

In related news: Two months after MicroCiscoYahooOraclesoft completed its controversial acquisition of Red Hat, questions linger about the accidental loss of all of Red Hat’s source code, revealed only last week. “Whoops,” said Darl McBride, director of open-source strategy at MicroCiscoYahooOraclesoft. “Don’t know how that happened. Pity all the backup tapes were destroyed, too.”

McBride pointed out that MicroCiscoYahooOraclesoft’s Server Customer Open Source program, or SCOsource, will offer Red Hat Enterprise Linux users discounts to license Microsoft’s Windows Server 2016 through May 15. After that, the company will remotely disable all Red Hat Linux installations. “We suggest you read the fine print,” McBride suggested, “and give up Linux before it’s too late.”

“We agree with that,” agreed The Suckup Group’s Suckup.

AT&T Goes the Distance

On a roll since its 2015-2017 acquisitions of Sony, The New York Times, Starbucks, Disney and Wind River, Apple Telephone & Telegraph surprised Wall Street by agreeing to be purchased by software giant GoogledellSUNokia for $3.7 trillion.

“The combination of our companies will be an unstoppable force for doing no evil,” said Eric Schmidt, chairman of GoogledellSUNokia. “We already have the world’s largest server farms, the most mature direct-sales model, the most online advertising, the best Android-powered handsets, the best embedded operating system, and the most complete logs about everything you do on the Internet. Plus, with gJava, you can write everything once, and run it everywhere. With AT&T’s resources, we’ll have even more amazingly cool handsets, the hottest personal computers, the most reliable wireless network and the most compelling content for you and your family, at home and at work. GoogledellSUNokia truly is the happiest place on Earth.”

Steve Jobs, chairman of AT&T, will remain on as honorary spokesmodel and chief platform evangelist for the combined company, to be named GoogledellSUNokiAT&T. During Macworld 2018, webcast from San Francisco’s Moscone Center last month, the normally recalcitrant Jobs had hinted that something big was brewing.

After unveiling the iPod notouch — the first music player with direct audio/video brain-feed capabilities — Jobs said “Something big is brewing.” At the time, analysts believed he was promoting the new AT&T Friends and Family Plan, which gives you 600 anytime iTunes movie rentals along with unlimited TV episode downloads nights and weekends, if you sign up for a two-year WiMax contract. For a limited time, each new subscriber also receives a Duetto Visa card, a Magic Kingdom three-day pass and home download of the Sunday Times. Severe penalties apply for early contract termination.

Perhaps Jobs had more than Mickey Mocha in mind, said Suckup of The Suckup Group, which recently placed both AT&T and GoogledellSUNokia into its Golden Sector of Industry Innovation & Leadership™. “When Jobs smiled after asking ‘Just one more thing: Don’t you love Google?’ at the end of his keynote, clearly something big was brewing,” Suckup said.

While GoogledellSUNokia’s Schmidt declined to discuss specific plans until the merger is rubber-stamped by the U.S. Federal Trade Commission and the European Union, he did say, “Someday soon, every phone will be an iPhone,” and hinted that one could expect to see Dell PCs, Sun servers and Nokia handsets appearing for sale in every iBucks location.

“Turning every Apple retail store into a Starbucks coffee shop, and every neighborhood Starbucks into an Apple store, was inspired,” said Suckup. “Getting a fresh iced latte from the iBucks Genius Barista while you download some tunes, upgrade your RAM, do your homework and work through some technical issues with GarageBand — that’s the ultimate in 21st-century convenience.”

Suckup continued, “If that level of service is extended to supporting Windows Panorama Edition 2017, that could give MicroCiscoYahooOraclesoft the much-needed opportunity to reclaim some market share from the iMac. Hey, that’s another reason to buy some stock.”

Stay Tuned

The three remaining high-tech companies that have not yet been acquired or merged — Novell, Borland and Salesforce.com — are reportedly thinking about it.

Retired software engineer I.B. Phoolen invented Web services, Scrum, penicillin, recursion and, most recently, ALGOL 68. Read his blog at ibphoolen.blogspot.com.

Code Blue!

How do you rank the severity of application defects? Some test teams assign severity/priority scores, but that’s arbitrary, and doesn’t reflect the real-world impact of bugs. How can you really assess the importance of something that’s rated “medium” for severity but “low” for priority?

More practical dev teams use expressions to communicate, through the defect database, change-management system, email or sticky notes, how important a defect is to the team. “This one’s a show stopper,” you might say. Or “If you can fix this before the next release, that would be great,” you might comment. Or “Who cares about a teeny-weeny typo?” you might write. Or “Sheesh, this one’s definitely gonna get us sued,” you might opine. Isn’t that better than “high,” “medium” and “low”?

However creative that approach is, the expression-based defect ranking system does leave things to interpretation. One person’s “it’s a teeny-weeny typo” is someone else’s “clean out your desk and be out of here before the cops come,” especially if that typo was in your CEO’s name, or in one of the digits in your upcoming Securities and Exchange Commission filing.

Similarly: While your CFO might issue a scathing four-letter expletive in both cases, which is worse: a bug that applies the wrong algorithms to stock-options pricing, or a bug that applies the wrong algorithms to a credit-scoring system? Selecting the “we’re totally screwed” button in the issue-defect system’s severity/priority may not accurately communicate the CFO’s displeasure.

The right solution, as I’m sure you will agree, is to hand these sorts of things to the U.S. Government. No, not the actually grading of your software’s bugs, you silly person: that’s your job, and you can’t get out of it. No, we should take a leaf from how our benevolent authorities have responded to airport security. You don’t hear the public address system at the airport say, “We’re at terror level we’re-going-to-die.” That would cause panic. Worse, it is ambiguous, since it doesn’t communicate who is going to die, when this will take place, and if you have time to buy a $5 Bloody Mary from a flight attendant beforehand.

Instead, as I’m sure you know, the monotone announcement on the P.A. system says something like, “Attention: We are at Homeland Security Threat Condition Orange.” This is more practical, and more useful, because it’s from the government and they know best.

That, my friends, is the model that software test/QA professionals should use when communicating with end users and other stakeholders about bugs, when assessing the bugs for ourselves, and when classifying said bugs in the defect database.

“Hey, Bob, looks like we’ve got a nice, juicy Yellow here,” you might hear shouted over a cubicle. “Are you sure it’s not Orange? We’re only fixing Oranges before the next beta,” you might shout back. And so-on and so-on.

The U.S. Government’s colorful Homeland Security Advisory System (HSAS) was enacted in March 2002. Forget about those silly “low,” “medium” and “high” scales that you see so often in defect-management systems: the HSAS goes much farther with five levels:

Red = Severe: Severe Risk of Terrorist Attacks
Orange = High: High Risk of Terrorist Attacks
Yellow = Elevated: Significant Risk of Terrorist Attacks
Blue = Guarded: General Risk of Terrorist Attacks
Green = Low: Low Risk of Terrorist Attacks

Brilliant, brilliant, I can hear you saying. Go ahead, say it again. Brilliant. Thank you. You can see instantly why this is appropriate for software development and test/QA. I would humbly propose the following scale for categorizing software threats. Actually, I would like to propose two scales, which I call the Software Defect Advisory System (SDAS). The first SDAS scale is the one that you tell your end users, managers and other stakeholders about, and which they use for reporting bugs to your test team:

Red = Severe: This Must Be Fixed Immediately
Orange = High: This Should Be Fixed Soon
Yellow = Elevated: Fix This When You Can
Blue = Guarded: Fix This Sometime, Maybe
Green = Low: Just Thought You Should Know

The other SDAS scale, of course, is more important, because it’s the one you use to categorize actionable issues in the defect database:

Red = Severe: This Will Get You Fired
Orange = High: This Probably Will Get You Fired
Yellow = Elevated: This Might Get You Fired
Blue = Guarded: This Probably Won’t Get You Fired
Green = Low: This Is Just Stupid

Follow this system, my friend, and you’ll never get scolded for misspelling the CEO’s name, or miscalculating stock option prices, ever ever again.

Bite Vulnerabilities Before They Bite You

April 1, 2007 — Firewalls are great if you’re worried about barbarians attacking your front gate. Intrusion detection systems are fine, if your goal is to see if unauthorized traffic is on your LAN; intrusion prevention systems work in conjunction with your firewall to block that unauthorized traffic.

Bah. Firewalls, IDS and IPS systems, as well as anti-virus solutions, spam filters, worm detectors — they’re all worthless, absolutely worthless, when it comes to attacking the real causes of software security failures. So, too, are checks against buffer overflows, cross-site scripting and SQL injection. While those vulnerabilities can trip up an unwary programmer, they’re easy to catch. Just about any static or dynamic code analyzer can find those problems. The real challenge is how to handle the most significant software security challenge of our time.

Puppies.

Yes, my fellow software architects, developers and test/QA professionals, the biggest threat to our software infrastructure, and the integrity of our data, is puppies. They look so cute, don’t they, with their lolling pink tongues, soft waggly ears and short little legs. They roll and play and want to be cuddled. But don’t be fooled. Puppies, those innocent little puppies, are placing your enterprise software in deadly peril… and your CEO, if the puppies start messing with your Sarbanes-Oxley systems. He’ll be going down the river… and you’ll be down there with him, if you don’t take action now.

Where did this insidious threat come from? It’s hard to know. Perhaps the first puppies merely wanted some fun; they wanted to show off in front of their litter mates. Nobody picks on the runt, you see, if he can erase breeding records with the click of a mouse. But then things got worse. Government agencies and their espionage programs. The military. Commercial interests. Terrorists and rogue states. They learned how to use puppies to bypass virtual private networks, routers, firewalls. How in the face of a determined puppy, even 256-bit AES encryption is about as effective as an old, battered squeaky toy. Buffer overflow exploits? Ha. Puppies sneer at your pathetic algorithms; you might as well not bother.

The puppy threat is years ahead of our technology. Check your Tivoli, your OpenView, your Unicenter TNG, even Microsoft’s MOM. Do any of them detect puppies? Not the latest versions, and not the current betas. Do they have any facilities for neutralizing the puppy threat, once detected? Not a chance. Microsoft Research, the T.J. Watson Laboratories — they’re hopeless. The experts at the Carnegie Mellon Computer Emergency Response Team are asleep at the switch. The Computer Security Institute doesn’t have a clue. Even the U.S. National Security Agency and Department of Homeland Security lack contingency plans to protect our vital enterprise software from the puppy scourge.

You should pool your resources with the rest of the IT team. Gather up your LAN and WAN managers, end-user support teams, data center managers, test teams. Heck, even bring the code librarian. Get the CIO or CTO to bring the team together — there’s no time to lose! Check out the RSA Conference or the Software Security Summit, neither of which (surprise) have classes or tutorials on puppy threat management. Ask, no, demand that they address this issue immediately We need classes. We need patches. We need an action plan!

Puppies. This time, the rolled-up newspaper is not going to be enough. Let’s get to work, people, before it’s too late.