Failure and Choice

The heart of software development is simply to SOLVE a problem not to aggravate it.

Shew

In my experience, an ideal web team consists of not more than 7 and not less than 5 individuals. At least half of the team members should be senior-level in their area of expertise. The functions of a web team can be categorized into five specialist groups: Design, Client-Side, Server-Side, Content, and Support.

Keep in mind that the context of this information is based on a web team. It would be ridiculous to assume that a single individual could fulfill all the functions necessary to develop complex web sites and applications (with rich content and in-depth transactions). The webmaster mentality is dated, if not dead.

Design In-Flight, Web applications: a Team effort — July 2005

Here's a train of thought that further proves to me that a good User Interface can make or break an application.

The thinking goes like this... To be really successful, a great strategy is to do a smaller number of things, but do them noticeably better than the next guy. In other words, don't spread yourself too thin. Nobody ever became fabulously successful by doing a long list of things in a mediocre way. If you want to get noticed, you've got to do something worthy of notice, something that most other people stop short of doing (because it's too hard, or takes too much investment for them to do). You need to take something to the next level. That's what gets you noticed and gets people talking. That buzz creates momentum and can bring all sorts of good things (reputation included) your way.

If you want to do something really well, a good place to start is figuring out what "well" means. By what factors will your task be measured? And exactly who will do the measuring? Knowing what buttons you need to push, and who owns those buttons is a tremendous advantage. It helps you plan your game - how you're going to go get that high score in the right people's eyes. It's worth a few minutes, days even, to make these things explicit. Think about them. Write them down. Once you've got a handle on those things, choices about how you're going to spend your time, what pieces of the overall puzzle you're going to invest your energy in become a lot easier to make. You can make wiser decisions. For example, the Dot-com bust taught a bunch of people that there's no point in investing heavily in getting "clicks" or "eyeballs" if you're ultimately going to be measured only by actual sales. Oops, a bunch of people were measuring themselves on the wrong scale.

Craig Fitzpatrick, If you get 1 thing right in your application, make it the User Interface — October 28, 2005

Ah, there's the rub. Perhaps you've noticed that it's getting more and more difficult to locate and then hire the best people. This isn't an illusion; it's real, it's significant, and it's only going to get worse. It is, in fact, the heart of the real software crisis: There is more software to be developed than there are capable developers to do it. Demand will continue to outstrip supply for the foreseeable future. Hence, more and more software will be behind schedule, over budget, underpowered, and of poor quality -- and there's nothing we can do about it.

"Nothing?" you ask. "What about better schools, better tools, better on-the-job training, better methodologies?" Those are essential because they raise the quality of most developers. But they do not solve the fundamental problem.

The conclusion I have reluctantly come to after more than 20 years of software development is this: Excellent developers, like excellent musicians and artists, are born, not made. The number of such developers is a fixed (and tiny) percentage of the population. Thus, the absolute number of such developers grows very slowly. At the same time, the demand for them expands rapidly due to the world's increasing use of, and reliance on, software.

Bruce F. Webster

Ironically, shipping late generally isn't fatal to a product. A third-rate product that ships late often fails, but if your product delivers value to its users, arriving behind schedule won't necessarily have lasting bad effects. If a product is a hit, it's not a big deal that it ships a month-or even a year-late. Microsoft Access shipped several years late, yet it has enjoyed formidable success in the market. Conversely, if a product stinks, who cares that it shipped on time?

Alan Cooper

When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn't have to lift a finger. Now that's what I call shipping software.

Mark Lucovsky - Shipping Software

Every company does things a little differently. Some rush the product out, features-be-damned. Others wait, and wait, and wait, until its "perfect". Some companies are secretive. Others open. And so on.

Certainly there is no set recipe for success (or failure). But there are a number of easy-to-avoid traps when building and presenting a product. Likewise, there are a number of "crowd pleaser" features that always get positive comments.

• First Impressions
• Rolling Feature Release
• Incomplete Features
• The Browser Issue
• Landing Pages
• Bloggers and Blogging
• Obvious Trust Issues

TechCrunch, Michael Arrington, Don't Blow Your Beta - January 9, 2006

Level 1: Beginner

• Little or no previous experience
• Doesn't want to learn: wants to accomplish a goal
• No discretionary judgement
• Rigid adherence to rules

Level 2: Advanced Beginner

• Starts trying tasks on their own
• Has difficulty troubleshooting
• Wants information fast
• Can place some advice in context required
• Uses guidelines, but without holisitic understanding

Level 3: Competent

• Develops conceptual models
• Troubleshoots on their own
• Seeks out expert advice
• Sees actions at least partially in terms of long-term plans and goals

Level 4: Proficient

• Guided by maxims applied to the current situation
• Sees situations holistically
• Will self-correct based on previous performance
• Learns from the experience of others
• Frustrated by oversimplified information

Level 5: Expert

• No longer relies on rules, guidelines, or maxims
• Works primarily from intuition
• Analytic approaches only used in novel situations or when problems occur
• When forced to follow set rules, performance is degraded

Jeff Atwood, Expert and Novice Programmers - February 03, 2005

Top 10 replies by developers when their programs don't work:

10. 'That's weird...'
9. 'It's never done that before.'
8. 'It worked yesterday.'
7. 'You must have the wrong version.'
6. 'It works, but it hasn't been tested.'
5. 'Somebody must have changed my code.'
4. 'Did you check for a virus?'
3. 'Where were you when the program blew up?'
2. 'Why do you want to do it that way?'

and finally ...

1. 'I thought I fixed that.'

C. Enrique Ortiz, Developer's Top 10 replies when code doesn't work... - October 14, 2005

Tired of estimates that are overly detailed, yet often wrong? To deliver working software that meets your stakeholders' needs, try an agile approach to requirements management.

It's reasonable to define what you're going to build before you build it; to identify the requirements for something before you code it. What isn't reasonable is defining all of the requirements in a comprehensive document before you begin implementation–experience shows that this approach is not only a poor way to work, but actually puts your project at risk. In the U.K., Andrew Taylor's 2001 study of 1,027 projects ("IT Projects Sink or Swim," British Computer Society Review) revealed that scope management related to attempting waterfall practices-including detailed, up-front requirements-was cited by 82 percent of failed projects as the number one cause of failure.

Why are people motivated to pack on the pounds when it comes to requirements? They often believe that they need all of the requirements defined before they can accurately develop cost and schedule estimates. However, according to the Standish Group's 2003 Chaos Report, 15 percent of projects are outright failures and 51 percent are over budget, over time or missing critical features. Also, many stakeholders believe that they need detailed requirements to ensure that they get what they ask for.

Software Development, Scott W. Ambler, Less Is More - November 2004

Significant opportunities to meet market and customer needs are emerging as corporations harness the next generation of "Web 2.0" tools and applications. Many business units recognize this and want to move quickly. But are corporate I.T. (Information Technology) departments ready–and willing–to provide the needed support?

Aligning business units and I.T. to take advantage of "Web 2.0" technologies is challenging but not impossible. The key to success is the appropriate definition of responsibilities, starting with two basic principles:

• Business units with customer communication responsibilities are ultimately responsible for the effectiveness of the content they communicate. They own the relationship with the customer. If being able to take advantage of new technologies in support of the customer relationship forces the company to redefine customer relationship management and how technology supports it, so be it.
• The I.T. department provides necessary installation, support, and standardization functions as well as leadership and strategy on technological matters. If this requires I.T. to develop new management approaches for handling externally supplied services, such approaches should be developed.

Jeremiah Owyang, Business and I.T. Must Work Together to Manage New "Web 2.0" Tools - January 4, 2006

If Architects Had To Work Like Web Designers ...

Dear Mr. Architect:

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have somewhere between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one.

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don't have nearly enough insulation in them).

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)

Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.

To insure that you are building the correct house for our entire family, make certain that you contact each of our children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.

Please don't bother me with small details right now. Your job is to develop the overall plans for the house: get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpet.

However, keep in mind that my wife likes blue.

Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features this house has. I advise you to run up and look at my neighbor's house he constructed last year. We like it a great deal. It has many features that we would also like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can't happen very often. Contact me as soon as possible with your complete ideas and plans.

PS: My wife has just told me that she disagrees with many of the instructions I've given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can't handle this responsibility, I will have to find another architect.

PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case..

Robert Watkins, Software is too expensive to build cheaply ... - October 18, 2004

6gate is a “transition mechanism” (a protocol used to ease the transition from IPv4 to IPv6). It allows a website to be accessible via IPv6 in the easiest possible way, without requiring any changes on the webserver. Therefore, it can be used by any domain no matter where the website is hosted.

We believe that the transition to IPv6 is important, and one of the main ways to get IPv6 to take off is to get websites IPv6 accessible. We want 6gate to be one of the catalysts that causes IPv6 to overcome IPv4. We have the tools and resources to do that.

When an IPv6 user tries going to your website, their DNS software will perform an AAAA record lookup of your domain. Their web browser will then connect to the IPv6 address in your AAAA record. So all we do is have you point your AAAA record to our gateway. The web browser connects to our gateway, and requests a webpage. We see that it is a webpage on your site, and we connect to your website via IPv4 and request the page, then sending it back to the IPv6 user.

Perhaps nobody thought of such a simple solution before. Maybe someone did, but they didn’t have the resources to get it done.

6gate, 6gate FAQ - 2006