Perfection vs. Functional: The Developer's Dilemma

When it comes to website development, there is a constant dilemma that goes on surrounding the question "How good is good enough?" Being as we work with such a pliable media, it's easy to get into the cycle of making things that work, and then build them up to meed demands and standards. However, at what point do we hit the point of diminishing returns?


For those unfamiliar with the law of diminishing returns, it is a economics concept that is used to determine price points for products and services. For every product or service, there is a maximal point of income where the quality of the product and the price a number of consumers are willing to pay are farthest apart.


For an example, you could sell a budget laptop for $500 at a profit of $50 per laptop, and lets say 1000 people are willing to buy it. That would give you a potential profit of $50,000. You could also sell a high-end laptop for $3,000 at a profit of $500 apiece, but then only 50 people are willing to buy it, giving you a profit of $25,000. However, in between you could sell a mid-range laptop for $1200 at a profit of $100 per laptop, with 800 people willing to buy it, giving you a profit of $80,000.


As you can see, as the quality of the product rises, the price consumers are willing to pay also rises. However, at the same time, the number of people willing to buy the product at the higher price typically decreases. Following these trends, there comes a point where producing an extremely high-quality product actually works against the seller, because the combination of profit margin and number of customers reduces total profit.


But yes, this is a post about websites and not about profit margins. As developers, we need to determine the point in which we've made a product good enough to justify the time and resources we put into it. If something requires a lot of our time, but doesn't benefit our work, should we still do it? What is the overall benefit to our end product? What is the cost if we do not do it? These are all questions we have to ask ourselves when we approach our work, since we don't want to subject ourselves to diminishing returns.

Internet Explorer 7, JavaScript, and Array Limits

I came across this a week or so ago while at work. It turns out that there is a limitation on Microsoft's implementation of javascript in IE7, but not one too many people might run into.

It comes in regards to array allocation. Whereas IE6 had no limit on the amount of array elements that could be allocated in memory, IE7 has a limit of about 8000 array elements. I'm not sure of the exact number, but that's usually about the point we were getting our cryptic "syntax error" messages. And to clarify, that's about 8000 total array elements in one page, not just in one array.

The good news is that you can get around this problem by using table objects instead of array objects. While a little more complex to work with in javaScript, they don't have any size limitations and can still get the job done.

Don't Just Do It...Do It Right

Over the past few years, I've really begun to see myself mature as a developer. It's not that I've learned any new mind-blowing code or languages, but instead in my development process and practices. I've developed an appreciation for well-documented and well-planned code, as well as for security practices.

Most of this maturity has been spawned by actually working with applications and databases that are meant to be used. When previously developing code on my own or for class, it was more along the lines of building a house of cards: I could put it together but it wasn't very stable. The application wasn't reasonably useful for anyone else.

While it may be nice to incorporate new features in our sites, like our faith, it's important to start with a solid foundation. We shoud strive to have websites that validate (or at least display consistently across brosers), catch errors, redirect bad links, and avoid making a visitor say "Uh Oh" or "What do I do now?" Not only that, but we should make them easy to pass on to someone else if the need ever arises.

It's something I can't even say is complete for this site (it's a long process when you can only do it in your spare time), but it's something I'm striving towards. It can be a long and not very exciting process, but in the end it does have it's rewards. Think of it as the "measure twice, cut once" of the programming world. In the end, it will save you a lot of hastles.

BlogCFC was created by Raymond Camden. This blog is running version 5.9. Contact Greg