Development

Overheard: Kent Beck, extreme programming and the quest for quality

I think it’s a combination of technical and social factors that leads to all the defects in deployed software. Part of it is the attitude that software is just inherently unreliable, and customers are conditioned to accept that. Developers are conditioned to accept that. Testers are conditioned to accept that. We just decided it was like the weather and there’s nothing we could do about it, which isn’t a very responsible position because in fact, there’s a lot that software developers can do about it. Kent Beck, as quoted in Extreme Programming inventor talks about agile development

Kent Beck gave a great interview that’s posted on the IBM developerWorks site, where he talks about the payroll project at Chrysler.  It’s a great read.

Now, the payroll program would handle Chrysler’s entire payroll, representing 1/10 of 1 percent of the entire US gross national product — at that scale, with union rules and all the places they operate, it’s a complicated program. They had a crying business need; it had to work. At the same time, this wasn’t rocket science — we just had to execute.

So, after a couple of weeks I interviewed everyone one-on-one. I told the first guy that we’ll divide the project into three-week intervals called, say, iterations. In each iteration we’ll implement a few new features called stories. We’ll write down all the stories we need, slot them into the iterations, then do it.

I told the next guy [I interviewed] that we have these three-week iterations divided into stories. For each story we’ll write these, um, acceptance tests to demonstrate that the stories meet the customer’s expectations.

With each person I interviewed I added a little more. By the end of the day, I’d interviewed 20 people and had laid out Extreme Programming’s basics.

My favorite quote from the article? “Sucks less isn’t progress.”

Overheard: Software testing explained

A software system can be tested in two ways. It depends on your point of view. It can be with or without technical knowledge of the system. Léon Meijer, Test-driven development, Unit Test, VSTS, NUnit, TestDriven.NET, whats all this?

Black-box tests can be functional or non-functional, though usually functional. The tester selects valid and invalid input for the test and determines if the output is correct. The tester doesn’t need to have knowledge of the internal structure of the system. Typical black-box test design techniques include:

• Equivalence partitioning; To reduce the number of test cases and select test cases that cover all possible scenarios
• Boundary value analysis Validates input and checks if the input is in the valid range, i.e. if (month > 0 && month < 13)
• Decision table testing Are about if- and switch-statements. Decision tables model conditional logic.
• Pairwise testing Test each pair of input parameters to a method. Simple bugs are triggered by a single parameter, next simplest category of bugs consists of those dependent on interactions between pairs of parameters.
• State transition tables Shows in what state a system moves to, based on the current state and input parameters.
• Use case testing Users work through use cases with the aid to verify that a UI fulfills the needs of its users, as described in the use case model. The tester identifies which use case(s) to test, the actors (users), input, output and system effects and the flows of interest between the use cases.
• Cross-functional testing The work of one person is reviewed by the team as a whole.

Overheard: The father of object-oriented programming

But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with “Remote Procedure Call” instead of thinking about objects and messages. Dr. Alan Kay (he coined the name OOP)

Doesn’t this quote remind you of Grace Hopper? She said: The most dangerous phrase in the language is, “We’ve always done it this way.”

If you want to learn more about the guy who “invented” object-oriented programming, Wikipedia has a good entry — but I absolutely love this video where he shares his ideas about how we learn. I HIGHLY recommend it. Apple should have a poster for Alan Kay. He thinks different(ly). My favorite quote of Dr. Kay’s is “The best way to predict the future is to invent it.”

Overheard: A good SOA architect is like an expensive wedding planner

Like a high-dollar wedding planner, an SOA architect can spare you mistakes and embarrassments while making the big event relatively painless, mostly by eliminating any unforeseen and unwanted surprises. Pam Baker, Best Reuse Plays in SOA

I laughed out loud when I read this analogy, picturing the CEO as Bridezilla and the rest of the executive board as the wedding party. Coincidently, Jason Bloomberg, over at SearchSOA.com, was just explaining that there’s a shortage of good SOA consultants right now.

Overheard: SOA - how do you measure success?

Combining both the Service-oriented Vitality Index and the SoROI provides a much clearer picture of a company’s SOA health. The Service-oriented Vitality Index, or SoVI, is the ratio of revenue generated from a service (or services) over the last 12 months as compared with all other existing SOA revenue… The SoROI is the cumulative before tax profits over “N” number of years from SOA-driven products divided by the cumulative product expenditures for that same period. Jerry Smith, 10 Measures for Successful SOA Implementations

Jerry Smith does a nice job breaking down some of the issues involved in making a business case for SOA. How do you measure success? And how do you get everyone to agree on the metrics? Jerry suggests there are ten ways you can measure success. All of them make sense to me except for SoVI. I need to go read more about SoVI and SoROI. Are they legitimate metrics or are they just biz-tech voodoo?

Overheard: Cuil will soon be a verb that nobody knows how to pronounce

The search engine’s launch was such a spectacular flameout that it may well go down as a verb. “What happened to that Eddie Murphy movie that was supposed to win him an Oscar?” “It came and went — it got totally Cuiled.” David Berkowitz, Do We Need Another…

There was tons of buzz this week — both in the media and in the office — about Cuil. The new search engine promised to index more sites than Google and it had some big industry names behind it. Everyone got all excited, hoping that Google finally had a real competitor. So what went wrong after the big reveal?

The engine works — it’s just not Google. And remember, Google is the supreme ruler. We build out sites for Google. We live and die by changes in the Google algorithm. Competing with Google is serious business. Literally.

Here’s how I knew that Cuil had disappointed and was already being dismissed. It hasn’t even been a week and there are already Cuil jokes.

Think about it. Have you ever in your whole entire life heard a Google joke?

———————–

P.S.

David Berkowitz’s quote made me laugh, but the thing I REALLY wondered when I heard about Cuil was this — what the heck were these brilliant people thinking when they named their engine Cuil?

NEW RULE: Never name your product something you need to tell people how to pronounce. For those of you new to the buzz-swarm, the word cuil is gaelic for knowledge and it’s pronounced “cool.”

Overheard: Justin Gehtland and continuous integration

All development teams (read: more than one programmer) have to deal with integration builds. This is where you pull together all the bits and pieces that the different team members were working on, and check to see if you have a fully functioning product or a Frankenstein’s monster. Justin Gehtland, Continuous Integration with CruiseControl.NET and Draco.NET

Justin Gehtland is great teacher. (That’s my highest compliment!)

Overheard: Version control best practices

Many developers are sloppy about commenting their changes, and some may feel that commit messages are not needed. Either they consider the changes trivial, or they argue that you can just inspect the revision history to see what was changed. However, the revision history only shows what was actually changed, not what the programmer intended to do, or why the change was made. Anders Sandvig, Best Practices for Version Control

Overheard: Extend your brand to the desktop

If your business has any kind of web presence, this could be a great tool for you. Why? Your customers don’t even need to launch a browser to find you. Your application, branded with your logo, could be sitting right on their desktop. Kyle Claypool, Tech Tools: AdobeAIR Apps

I’m not so sure about Adobe AIR apps. I can clutter up my desktop quite nicely by myself. I’ve already ditched my gadgets and widgets. The AIR apps look pretty but I still think I’d rather go to a web page and keep my desktop for my own clutter. I must say, though, that Kyle’s examples almost have me convinced to give it a try.

Overheard: XHTML or HTML 5?

What started to get under my skin was the fact that I spent a lot of time writing XHTML, but serving it as text/html. Why? Because the servers to which I was publishing are configured similarly to 99% of the other servers powering the Internet. Jonathan Christopher, Siding with HTML over XHTML, My Decision to Switch