test

test

Buggy software: Why do we put up with it?

This is a guest post by Michael Kassner via TechRepublic's IT Leadership blog.

During one of the breakout sessions at TechRepublic's Live 2010 Conference this past week, I was questioning why we put up with software that has bugs and vulnerabilities. To IT-security types like me, it's a concern. Eliminate bugs and you shut the door on most malware.

After that particular breakout session, Toni Bowers, Head Blogs Editor for TR, and I talked about my concerns. She suggested that I pass what I learned on to you. So, here goes. I cajoled the "software savvy" TR writers into answering the following question:

Consumers would never accept a car or other traditional goods that are flawed, yet they are willing to buy software that is. Why do you think that is?

Here are their answers. I hope you find them as interesting as I do:

Chad Perrin

The question of why software vendors produce buggy software and why consumers accept it has no simple answer. The reasons vary from incompetence plus overconfidence to being the dominant business model at the other extreme. Here are some of my thoughts:

• The dominant business model in the software industry is one that creates and relies on otherwise unnecessary complexity. That complexity both creates bugs and hides them from view. Paraphrasing C. A. R. Hoare, there are two ways to build software: Make it so simple that there are obviously no bugs, or make it so complex that there are no obvious bugs. The former is much more difficult and does not lend itself well to enticing people to upgrade to the next version.
• People are so focused on feature marketing that they do not stop to think about bugs until it is too late. After generations of this, and of the problem getting worse all the time, end users have developed a sort of Stockholm Syndrome with regard to buggy software. They believe it is normal, expected, and inescapable.
• Features and bugs act very similarly a lot of the time once software exceeds a particular level of complexity. They do things that are surprising, or at least unexpected. People grow used to this until they become inured to surprise without the surprising behavior being reduced at all — in fact, it only gets worse. "It's a feature, not a bug" starts to sound reasonable and believable.

Chip Camden

Having worked in auto parts for several years, I can tell you that very few cars roll off the assembly line without any flaws. That's why they have a thing called recalls.

Furthermore, a serious flaw in an automobile can cost someone's life. That usually isn't the case with software, and where it is the case (medical, missile guidance, aircraft navigation), then the extra expense of a higher attention to flawlessness is considered worthwhile.

Ultimately, it's market-driven. We could make software that performed to much more exacting tolerances, but it would be much more costly. The buying public is content to pay a near-zero cost for "good enough" rather than putting a dent in their wallets for "flawless." [Editor's note: you can read more from Chip Camden in TechRepublic's IT Consultant blog.]

Erik Eckel

I think the software industry is very different from most any other. Vendors must try writing software that will work on multiple platforms (Linux, Windows, Mac) and be used by a variety of users with greatly differentiated skill levels at companies working in numerous different industries. That's a pretty tall order.

Imagine trying to make a car that could be driven by a 5′4 woman or 6′5″ man that could run on gasoline, diesel, or propane; while also possessing the ability to carry up to eight people or 6,000 pounds of payload. Oh, and it must get 28 miles to the gallon and cost less than $25K and go 100,000 miles between tune-ups.

You couldn't do it!

So, I feel for software manufacturers. The Intuits, Microsofts, Apples, and Symantecs of the world have a wide constituency to satisfy. Someone's always going to be complaining.

I think the 37signals guys may have it best. In their current best-seller ReWork, they note that one of the keys to their success is saying no to customers and limiting the amount of features they include in their software programs.

I think there's a lesson there for all of us. [Editor's note: You can read more from Erik in TechRepublic's Macs in Business blog.]

Jack Wallen

The answer is very simple: Marketing. If you ask the average consumer (those who buy the bulk of computers) if they knew there was an operating system out there far superior, safer, and more reliable than the one they used AND it was free, they would react with surprise. Their first question might be "Why didn't we know about that?" The reason is because Microsoft is a HUGE company with a HUGE PR budget and the ability to shove advertising down the throats of the consumers.

To continue with your analogy:

Tesla has a roadster that is 100% electric, can go over 300 miles on a single charge, can go from 0 to 60 in 3.7 seconds — yet the majority of people don't know about it. Why? Marketing. If one Linux company could start to produce witty, well-done television commercials things would quickly change.

But think about this: Linux has done fairly well for itself without having to spend a penny on advertising (relatively speaking). Word of mouth has been a powerful alley to the Linux operating system. However, in order to raise it to a higher level, PR and marketing will have to be used. [Editor's note: You can read more by Jack Wallen in TechRepublic's Linux and Open Source blog.]

Justin James

Some thoughts that come to mind (as someone struggling with a phone heralded by others and the media as a "miracle phone," but it is plagued with problems):

• "No warranty, express or implied" is attached to every piece of software ever made and is enforceable. Consumers know that they have zero rights, so they feel happy when it works.
• "Gadget lust" blinds people to issues. People don't want to admit that they bought a piece of junk, so they just deal with the problems and tell everyone how much they love the software/device/etc.
• In corporate environments, the people who live with the bad software are often the people who do not pick it. Those who did select it sweep the problems under the rug because it makes them look bad, or they feel it's a question of "stupid users" who "just don't get it."
• Too many problems do not appear until whatever initial return period of contract cancellation period is over.
• People expect to have problems.
• People assume that the problems are their own fault ("I'm too dumb to use this right!").
• In corporate environments, many products require a lengthy and expensive integration process; there is no way to accurately judge their quality until that is done, and afterward, it is often not clear if the base product or the integration work is the root cause of problems. To make matters worse, once you dump, say, $150,000 into customizing a $200,000 package that you spent $50,000 on hardware to support, do you really want to say, "gee, it looked good when we started, but this is a dud, let's dump it"?

Overall, it's a combination of people feeling helpless on the user end of things, and the decision makers being unwilling or unable to do anything about it once a commitment is made. [Editor's note: You can read more by Justin James in TechRepublic's Programming and Development blog.]

Patrick Gray

I think there are two factors at work that would cause me to question your premise:

Perceptions of software "flaws" are often based more on market saturation than technical elegance.

Most mainstream technical products (hardware and software) seem to have a higher incidence of flaws because they have a higher user base. This is the classic "Windows is buggy versus [a more obscure OS]" argument.

I don't think Windows is inferior, it's just a mass-market product and thus gets used and abused by the highest percentage of the population. Because Mac OS X has gained traction, it's now getting hit with malware as more people use the software rather than due to some inherent flaw.

There are considerations that outweigh flawed products, mostly getting valuable features early.

I think technical elegance often becomes second fiddle to other concerns at both a corporate and personal level. Why? We want new features and are willing to put up with partially baked software. This extends to your automotive analogy as well.

I bought a new motorcycle from BMW in its first model year (ever hear the old bromide never to buy the first model year vehicle?). The bike has had four recalls, including replacing the front axle (a front axle failure at 80 mph would be bad). Despite this product having flaws, the trade-off of having an extra year's riding was worth it to me.

If we all wanted perfect and bug-free code, first and foremost, we'd probably all be running MS DOS or a text-based Linux that hadn't had any features added in a decade. [Editor's note: You can read more by Patrick Gray in TechRepublic's IT Leadership blog.]

Rick Vanover

While software quality should be the first priority in whether or not we implement something, many times IT customers have their hands tied. Simply forgoing a piece of software if all offerings will not meet their needs will not be an option.

The natural alternative is to develop something in-house, but that too, may be cost prohibitive. This is an age-old battle of having our hands tied in a way to get pushed along to new products, and history has done nothing but continually confirm this for us.

One example is the file server market, Novell NetWare is still a superior file server product to Windows NT, 2000, 2003, or 2008; yet we all know which way the market and broader supported configurations went. There is no simple answer on how we can address this, in my opinion. [Editor's note: You can read more by Rick in TechRepublic's Network Administrator blog.]

Final thoughts

It seems we the users want the latest and greatest software, even if it means accepting buggy code. Do you agree with the TR gurus? I know we all are anxious to learn your opinions, so let them fly.

Chad Perrin wanted me to mention that he has a lot more to say about this subject. Please look for his article in the IT Security blog of TechRepublic.

Excerpted from Buggy software: Why do we put up with it? ZDNet

Parent Child Relationships in VBCs - BC User Property : "Populate Child Data"

Virtual Business Components provide for a nice way of presenting data via WebServices. Each time the VBC is loaded/refreshed in the UI, the integration is triggered behind it, and resulting response appears in the UI. But what if there is a parent child relationship in the data being returned and the requirement is to present each set of the hierarchy in a separate applet ? In normal BCs, the data is pulled from the tables, and if links are provided, the child BC gets refreshed when the parent BC is changed. How can we achieve the same in VBCs ? There is a little unknown BC userproperty “Populate Child Data”, which can be used to achieve this nice effect, without scripting, or repeatedly invoking the webservice. Here is what you do.

 

·         Create the two VBCs and the two applets for them. Also created the BO and View based on the BO.

·         Both the VBCs must refer the same IO,either via the BC userpoperty “Outgoing Integration Object Name”, or the IO name gets hardcoded in the WF.

·         The IO should have two ICs, one for parent level and one for child level in response data. The external names must be correctly populated with the BC names created.

·         Link must be created between parent and child BCs. This BC has to be added in the BO.

 

Now if everything is correctly configured, compile everything and fire up the client application. Navigating to the view will bring the data correctly in the two applets, correctly maintaining the parent child relationship between them. Moving to the next record at parent level will refresh the child level data, as the link is in context.

 

Now go ahead and check out the integration logs for this integration. There is a nice tutorial here.

 

You will find that the webservice integration was actually triggered twice, once for each level of hierarchy. The same request goes out and the same response comes back, so it means double the work. Now :

 

·         Go to the child BC you created. Add a new BC userproperty :

·         In the name column, provide : “Populate Child Data”

·         In the value column, provide : “Y”

 

Compile the BC and load the view again. Data still comes as expected in the UI alright, but if you check the integration logs, you will see that the web service was invoked only once.

 

BC user property “Populate Child Data” doesn’t look documented in bookshelf or supportweb. If you are not happy with this approach, there is a scripting alternative suggested on supportweb here.

 

 

 

Nice process, but what about the engineering bits?

Nice process, but what about the engineering bits?

via http://ayende.com/Blog/Default.aspx by Ayende Rahien on 2/19/10

Software processes has always been a popular topic of discussion in our industry. Those can get quite heated, with advocates of the "stable / stale" Waterfall method pointing fingers toward "rapid / rabid" Agile methods, with the CMMI people throwing documents around and Lean people standing on the sidelines muttering about Waste.

This isn't a post about a specific software process, I'll defer that to another day. Instead, I want to focus on a flaw in the basic building blocks in many* software building processes.

They ignore the actual building the software.

That may sound ridiculous on the face of it, after all, how can a software process ignore the act of building software. But take a look at the following diagrams:

If you'll pay attention, you'll notice that those processes talk about everything except how to actually build software. They talk about people, about requirements, about managing customers, about a whole lot of things, but not about the part where you have people sitting down and writing code. In most of those, in fact, that part is usually defined as one of those:

Why is that a problem? After all, isn't there a big distinction between software engineering (we know what to do, now let us do it) and project management (getting to know what we need to do, and verifying that we did it right). Those processes deal primarily with project management and leave the engineering part to be defined in a way that fit that particular project. Surely that is better, right? In theory, it might be. But there is a big problem when you have a software process that ignore the software engineering aspects of building software.

The problem is that that in many cases, there are hidden assumptions that are going to hammer you down the road if you use a certain process with engineering practices that doesn't fit it. Take a look at the following chart, showing a team velocity over time, does this look familiar?

The term I heard used for this is Scrum Wall, but I have seen similar results in other processes as well. The best description for that is Allan Kelly's:

You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don't work any more - to use an English expression, they go pear shaped. You can't keep your commitments, you can't release software, your customers get annoyed and angry, it looks like Scrum is broken.

This is what happens when you adopt Scrum without technical practices such as Test Driven Development, continuous integration and refectoring. When teams adopt the Scrum process, they go faster, show progress, things look good... and then the quality becomes a problem. Now the team are fighting through quick sand.

The code quality is poor and developers are expected to continue to make progress. Maybe the Scrum Master/Project Manager reverts to past behavior and demands overtime and weekend working. Maybe the team start busting a gut to keep their commitments. Either way the team is heading for burn-out.

The major issue is in focusing so much effort and time on project management with what amounts to willful ignorance of the technical and engineering practices will inevitably leads to disaster. The process of building software is intractably linked to the engineering practices involved in building the software. Moreover, some technical practices are actively harmful in some scenarios and life savers in others.

Many Agile and post-Agile processes focus on short cycles, each of them producing something with a distinct value to the customer. That may be an iteration, a commit or a feature, where the goal is to increase the velocity over time so we can provide as much value to the customer in as short a time as possible. What those processes ignore are things like technical debt, large scale refactoring and non functional efforts. Oh, you see those things mentioned on the edge, but they aren't something that is dealt with heads on, as a core issue to consider.

There is a bit more to that, actually. The software engineering practices and the project management strategies are linked and of paramount importance when the time comes to decide how the software should actually be built. No, this is not tautology. We just need to take into account Conway's law and expand on it a bit.

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.

Part of the design process of a project should include design the team(s) structure, the project management strategy and the software engineering practices in order to align the end result with what is desired. Ignoring this leads to imbalance in the project, and if that imbalance is big enough, and goes on for long enough, the project is going to rip itself apart.

* Nitpicker corner: I said many, not all. Don't bother to list me software process that deals with it. I had a reason to explicitly list the processes that I did.

Javascript trick to quickly navigate views.

Siebel’s hierarchical way of organizing views under sitemap is a useful feature, everything is arranged under screens as per context. But sometimes the only way to access a certain view is to go via the sitemap, and specially for administrators, this means sifting through pages of links to find the correct view. Being an Seibel EAI integration developer, I find myself frequently visiting three main views in Siebel application, on my local as well as the thin client. Most of my work can be done on tools, but Datamapper Administration View, Workflow process instance and webservice administration views are my mostly visited views.  Inorder to make navigation easier, I used to create bookmarks in the browser using the GotoView command to quickly take me to a view.

 

 

But this meant and different set of bookmarks for local client, and a different set for every server/environment. So I ended up using javascript to do the navigation for me.

 

Create a bookmark in your internet explorer, then enter the text below for Business Service Simulator view

 

javascript:var url = new String(window.location);var p = url.substring(url.search('start.swe?') ,url.length);p=p + 'start.swe?SWECmd=GotoView&SWEView=Business Service Test View' ;window.location(p);

 

Once you have logged into your siebel application (local/server), just select this bookmark , and you should be taken to that view.

 

Here is the bookmark for Datamapper Adminstration View

 

javascript:var url = new String(window.location);var p = url.substring(url.search('start.swe?') ,url.length);p=p + 'start.swe?SWECmd=GotoView&SWEView=EAI DTE Data Map Editor' ;window.location(p);

 

 

Code junkies can edit the code and add any view wanted.

 

Just discovered John Mayer

Just discovered John Mayer. Nice soft care free style.

Toy Story 3 - best movie of this year.

We have been through half of this year, and the only movie which stands out clearly is Toy Story 3. I have always loved animation. I love the way animators are able to make people laugh. But I am even more intrigued when they are able to turn people emotional, or even make us cry.  The first time I saw this was in Disney Pixar’s Up! There is a complete sequence of storytelling with moving images and soothing background music, but not even a single bit of dialogue, but it turns the viewer emotional. The only that stopped me from sobbing was that I was watching it at home, and not in the theatre.  And now , I had a similar feeling of nostalgia when I watched Toy Story, specially the ending. Again, there is no piece of dialogue meant for the viewer, it’s just animated sequences of last looks, and silent goodbyes. And music. Beautiful music.

 

At home, I still have some of my old toys, salvaged and preserved in the drawing room show case. It’s a bit of younger me. And old monkey my dad brought from Germany. A toy dog which still barks if batteries are inserted. The movie made me think, how did I feel when I outgrew my toys..sigh, don’t remember.

 

 

If you haven’t watched Toy Story 3- you are missing the best movie of this year……at least, so far.