(Or how to say no to your customers)

Henry Ford said famously in reference to popularizing the automobile: “If I had asked people what they wanted, they would have said a faster horse.” Instead, Ford thought more broadly and created a product that addressed the true needs of his customer. Similar discrimination is key in any creative industry, and particularly in software development.

Throughout the development and ensuing public release of our quoting software, Socket, we encountered countless ideas and suggestions for new features from both our own team and our customers. Many were great and would likely serve useful to at least some users, however only a few truly fit the greater goal for our software. Since our goal was to build a sales quoting system that takes care of the grunt work without unnecessarily complicating the process, only a few made it through our gantlet of validation questions.

Scratch your own itch

To produce an effective piece of software, a developer must have a clear vision for the goals and design of his product, and must be judicious in deciding what features will and will not make it in. Intimate knowledge of the problem domain is necessary to ensure that the end solution achieves its goals in the least complex manner. The best way to ensure the efficacy of your software is to start by scratching your own itch — developing a solution for a problem you are naturally familiar with. Naturally, though, this can sometimes come at odds with what customers seek.

Needs do not equal wants

Customers don’t always see the big picture, and often misunderstand their real needs. They can often become impatient with a feature, and try to misuse it in an unintended way. In response, it’s often easy for the customer to request new ways of doing what they specifically have in mind.

On the other hand, as a developer, acting on every feature request would quickly turn your product into “bloatware” — bogged down by layer upon layer of confusing and redundant features. (By the same token a developer’s own visions can also lead to boundless “feature rampage”, so restraint must come from within, too.)

“Say no by default”

Jason Fried and David Heinemeier Hansson, in their book Rework, give the advice to “say no by default”. The benefit of this position is that popular requests will make themselves heard repeatedly, making it easier to evaluate their importance.

Despite turning down a request, saying “no” doesn’t have to mean leaving your customer high and dry. You can still be diplomatic in response, and even helpful. Often there is an alternative and perhaps simpler solution that will work just as well at solving the problem at hand, without needing to complicate the software.

Your vision must withstand the tests of time

Inevitably, customers will eventually grow out of your product. Resist the urge to grow with them by relentlessly expanding scope, because such a pursuit might risk alienating new customers whom you’ve been targeting all along.

With a clear vision, and as you begin to acquire customers and build an understanding of their needs, it will become easier to thoughtfully refrain from adding undue features — while knowing when to move ahead with those that truly benefit your target market and best serve the product.

We got a heads up from our friends at Invoke Media about Make Web Not War hitting Vancouver (now totally sold out!) and we thought it would be a great opportunity to check out what they have to offer and network with fellow web devs. The event is on May 7 at Masik Studios and will showcase a ton of new web tech. We’re most interested in the cloud computing aspect, as our new SaaS product Socket is hosted in the cloud (Rackspace). With the impressive advances cloud hosting and cloud computing in general has experiences in just the last few years, it will be exciting to take a peek into the future and see what we can look forward to.

You can check out more info on their website: http://www.webnotwar.ca – hope to see you there!

I was looking for a nice loading animated .gif for a site I was working on today, and stumbled upon this site and thought I’d pass it along: http://preloaders.net

When storing currency (or any decimal number for that matter) in mySQL, it’s extremely important to be aware of the differences in the decimal place storage methods available. Doubles and Floats are imprecise storage methods (as they use floating point arithmetic), and can lead to major problems when representing currency, as the cents value is obviously important. Thus, always use the decimal type for currency or money storage in mySQL! In most cases, 10 digits before the decimal place and 2 digits after should be sufficient, as shown in the screenshot of phpMyAdmin below.

phpMyAdmin screenshot showing how to properly store currency/money in mySQL

Deversus is pleased to announce that it has launched a location-based iPhone application, built on its proprietary Find Closest Framework. BoozeHound — an innovative liquor store finder app for Canadians — allows people to find the nearest liquor store with a single touch of the finger.

Developed in partnership with Zygoat Creative Tech., BoozeHound was designed to be simple, effective, and efficient. Built on our innovative “Find Closest” platform, we’re confident that BoozeHound is second to none in its ability to find the nearest liquor stores with ease. The platform boasts some impressive location-aware capabilities, such as realtime connectivity to a geo-spatially indexed database via web service, intelligent map browsing and caching, and inaccurate location reporting. Users of the app will appreciate the quality and quantity of the liquor store data, which includes phone numbers and store hours for most provinces.

The app makes its debut on the Canadian app store on December 1st for $1.99. For more information about the app itself, check out the BoozeHound website.

BoozeHound: iPhone Liquor Store Finder App

We recently upgraded our web server to a dedicated package with 1&1. After being moved to the wrong type of server, we called 1&1′s customer service department to try and have the issue resolved. Our experience with them was so bad, I’ve decided to write a short article about the importance of customer service and the consequences that even one bad customer experience can bring.

Our Attempt to Upgrade Our Hosting Package with 1and1

The issue, in a nutshell, was that we were misinformed about what server package we were being upgraded to. Being a customer with 1&1 Internet for about 6 years (transferring the account from my old web development business to Deversus in between), we’ve grown to the point where we require a dedicated web server to meet our needs. I used 1and1′s Switch Package feature via their control panel to process the upgrade. The Switch Package experience was awful, at best. It gave a terse listing of the available servers and their associated costs, with no description or links to indicate what the server package contained. After Googleing the package of interest (the 1&1 Dedicated Server Dual-Core M Website), we decided to go with that (as a caveat, the Dual-Core M package description we read was from the 1and1 UK website and is no longer on the US website).

Three days later, the upgrade was complete — sort of. It was at this point that we realized we had been upgraded to 1and1′s “dedicated managed server” and not a “dedicated root server” like we were expecting. We hadn’t a clue that there was even such an option. While one could blame us for not doing our due diligence to make sure of what we were getting, the general lack of information throughout the process was simply unacceptable.

Our Attempt to Resolve the Issue with 1and1′s Customer Support

I first e-mailed 1and1′s support@1and1.com address to inquire about the issue and attempt to have the managed server changed to a root server. After being told that there is no way to stop the upgrade process or change to a root server, and that I would need to purchase a separate server and migrate the files myself, I decided to call their customer support team.

It was downhill from there. I was transferred a total of 7 times, back and forth between departments, and placed on hold for 45 minutes. After trying to escalate the issue, I was told I would have to call their Germany office (which conveniently, was closed for business). The primary conflict was surrounding the fact that their Dual-Core M Website package was apparently no longer available. I was told that I would need to switch to a lesser package, in which case the server paled in comparison to the Dual-Core M, albeit for $10 less per month. Or, switch to the Dual-Core M package — a similarly spec’ed server — for nearly twice the price. Long story short, the best they could do was offer one month free for the Dual-Core L package, which I decided was petty. After an awkwardly long silence, I let them know that we would be pursuing a different hosting provider.

The Moral of the Story

As I so politely asked the 1and1 CSR, “what would you do in this scenario if you were the CEO of 1and1?”, there exists a big picture mentality that most customer service teams are simply not trained in. While perhaps insignificant to the overall profitability to their company, our $59/month over the next five years translates into $3540. This assumes, of course, that we don’t upgrade or add more servers to our account. Not to mention, being a custom software development company who deals with numerous other large companies with extensive server requirements, we are able to bring a lot of potential new business to a company like 1and1. Or what about the fact that I had such a bad experience that I felt compelled to write a blog article about the importance of customer service and the consequences a bad experience can have?

While I don’t hold any one of the individual CSRs I spoke with at 1and1 accountable for the inability to resolve our issue, I am in disbelief that it is possible for a behemoth of a company like 1and1 to instill such shortsightedness into their employee training.

I know that at Deversus, we value our client relationships because they are our lifeblood. We go out of our way to make sure our clients are happy with the work we do for them and if there is an issue, we do anything within reasonable means to resolve it.

Today we are proud to unveil the third version of our corporate website, deversus.com. We’ve given our new site a beautiful Web 2.0 look and feel as well as expanded our testimonial and showcase sections. Our services section has been separated into distinct categories, too, so you can easily find what’s most relevant to your business. Also, we built the site using our in-house CMS, which will allow us to easily keep our content fresh. If you have any comments or feedback regarding our new site, contact us or leave a comment here!

The second big announcement for the day is the release of our new customer referral program. We base our marketing strategy almost exclusively on impressing clients and encouraging word-of-mouth referrals. With our new program, if you send a project our way, you’ll earn Development Credits that you can use towards your own future development projects to help offset the cost. By earning Development Credits, you could save up to 30% of the development costs for your next project! Read about it here.

As always, comments and questions are welcome!

Over the years developing web sites and web applications, we’ve noticed a couple things about our development process. We’re very passionate about the work we do and we love to go that extra mile for our clients. As such, there is a great temptation to investigate and utilize new, cool technologies and deliver snazzy features to enhance our projects. At the same time, we must be very aware of our clients’ budget and ensure they are receiving the features they need before the features they (or we) want (as described in our Requirement Engineering article). Furthermore, there are features that can creep into projects that are nice to have, but mostly unnecessary. The term gold plating describes this collective set of features.

Gold plating is the addition of features that may be nice to have, but are unnecessary. During the initial requirements engineering phase, we work with clients to identify and prioritize all features. Then, we determine which features are considered gold plating by asking a couple of questions. First, is the feature in question going to save the client time and money? How often will the feature be used? Will the feature impress the website viewer, and entice them to respond favourably (perhaps by making a purchase, or filling out a contact form)? Is the estimated benefit of the feature worth its implementation cost? In regards to visual features, is there a way we can implement the same functionality in a more cost-effective manner (i.e. AJAX compared to a page refresh)? Do we have enough information to ensure the feature is completely necessary? Sometimes it is best to identify, develop and deliver the must-have features first, and then determine if a feature is necessary after it the system has been put to use for some time. As we go through these questions, we get a better idea of how each feature should be prioritized so we can steer away from gold plating, and save the client development time and cost.

The key to developing a cost effective custom solution lies in the analysis of the requirements – specific to this article, the identification and elimination of gold plating. Sometimes the client wants things they don’t need, and sometimes the client needs features they aren’t aware of. As software development consultants, we have a responsibility to understand the issues that need to be addressed with the software solution. This way, the client receives a great custom solution in the most time and cost effective manner possible.

Requirements engineering is the first and most critical phase in the development of custom software. During this phase, we take an in-depth look at your current business processes and how we can address problems or bottlenecks with a custom built solution. This phase is absolutely critical to the current and future success of the software; without it we are building a house without a blueprint. The only way to validate the success of a custom software endeavour is to understand what needs to be delivered. Thus, without understanding the requirements, we can never hope to deliver a successful system that our clients would be happy with.

There are numerous benefits that arise from an in-depth requirements analysis. Some include:

• Great understanding of development time, and therefore cost. Based on past development experience, we are able to take a brief look at a proposed system and generate a ball-park estimate. After completing the Requirements Engineering phase, we are able to improve from ball-park range to eye of the needle, where we will agree to a fixed price quote for your software.

• Our development team gains invaluable insight into the software they will deliver. The understanding our team gains while spending time with the end users will dramatically reduce the development effort, saving our clients’ money.

• Prioritization of requirements allows for the delivery of a usable system in the most time and cost effective manner possible. We work closely with our clients to place requirements in priority order before we begin development. Since software is constantly evolving the ‘should-have’ and ‘nice-to-have’ features can be planned for and added after a working system is in place.

Take a look at our requirements engineering process outlined below. You will learn about the each phase of the process and discover the deliverables produced at the end of this important phase. Comments and suggestions are greatly appreciated.

Requirements engineering is the first and most critical phase in the development of custom software. This process encompasses all tasks involved in eliciting, analyzing, specifying and validating requirements. The ultimate goal is to generate a set of requirements which can be used by the software development team to build the necessary software. This phase can be broken up into four related sub-phases.

1. Requirements Elicitation

This is the process by which users of the system are interviewed in order to reveal and understand their requirements. This sub-phase involves a high level of client input.

2. Requirements Analysis

This is the process by which elicited requirements are evaluated for consistency, similarity and scope coverage. Requirements are triaged; that is, placed in 3 separate categories:

a) Must-have
b) Should-have
c) Nice-to-have

Through this process the most relevant, mission critical requirements are emphasized and developed first. This ensures the final product satisfies all of the important requirements, and does so in the most time and cost efficient manner possible. Other “should-have” and “nice-to-have” requirements can be relegated to future phases, should they be necessary. Once triaged, the requirements are divided into phases and milestones, which will be mapped to the project estimation and timeline (see next paragraph). For example, Phase 2 may consist of implementing every “must-have” feature. A milestone within that phase may consist of implementing Use Case x, y and z (See ‘Use Case document’ below for the definition of a Use Case). By scheduling the project in this iterative way, our client has a good understanding of when certain things will be delivered and when their input will be required. Additionally, features are generally developed in a “vertical” fashion; once Use Case x has been developed, its unabridged functionality can be demonstrated to the client. In this way, our client has a clear understanding of where development time is being spent, and potential issues can be caught early and dealt with efficiently.

3. Requirements Specification

This is the process by which requirements and their analyses are committed to some formal media. For this project, we would generate four documents during this sub-phase:

a) Use Case document: a use case is a description of the system’s response as a result of a specific request from a user. Each use case will cover certain requirements discovered during elicitation and analysis. For example, a use case may cover “Adding a New Employee”, or “Generating Site Report”. User interface requirements are completely ignored at this point; the goal of the use case is to document system behavior at a high level. Thus, the use case document is simply a collection of logically ordered use cases that will encompass all currently discovered functionality.

b) Interface prototypes: an interface prototype is a rough representation of certain critical functionality, recorded as anything from a hand-drawn image to an elaborate HTML mock-up. The prototypes are completely horizontal in nature; they roughly illustrate how the interface for a certain feature will look and what information is accessible but they will have no back end (vertical) functionality. This will allow us to design a system whereby the important functionality is easy to access and use. Additionally, these prototypes tie in heavily with the triaging process; since screen real estate is of utmost importance when presenting information, by knowing which data and functionality is most important it can receive the most attention.

c) Architecture Diagram: an architecture diagram will be generated for developer use as it is a high level view of how the software will be structured. Only if we feel it will help in our understanding of the system will this document be created.

d) Database Diagram: as with the architecture diagram, a database diagram is generally created for developer use. Through these final two media, we are beginning the shift from words (requirements) to code (software). By generating these two documents we can effectively explore different ways of satisfying the requirements through the software and achieve a more technical understanding of how we will proceed once the development begins.

4. Requirements Validation

This is the final phase of the requirements engineering process. It involves scrutinizing the documents generated during the specification sub-phase and ensuring their relevance and validity. This must be done by all interested parties (which may include the users of the system, financiers of the system and Deversus as the developer) so they are in agreement with the proposed system’s behavior, especially in the case of the Use Case document and prototypes.

Project Estimation and Timeline

As requirements are elicited, analyzed, specified and validated, we will be estimating most features. This is an on-going process that will culminate in the delivery of the Project Estimation and Timeline document. This will outline the duration of work required to develop and deliver Phase 2. As indicated in the Requirements Analysis sub-phase, Phase 2 will likely consist of the majority of the “must-have” features; however it is ultimately up to the client to decide what is most important (even within the “must-have” category), and this will be developed first.

Conclusion

Though the aforementioned processes are part of “Phase 1″ of our software development lifecycle, realize that this process is always occurring. It would be unrealistic to think that everything required from the software can be uncovered during the first phase. Constantly re-analyzing our requirements documents throughout the development process will ensure the risks associated with change are caught early and thus mitigated. Therefore, we can be sure that the Use Case document, for example, will be a “work in progress” piece that is constantly refined throughout the development lifecycle.

The first phase of the software development lifecycle as outlined here is absolutely crucial. In order to build any system correctly and effectively, its purpose must first be established. By carefully defining the requirements of the software at this stage, we can ensure the delivery of a solution that streamlines operations, lowers costs, and provides lasting value.

Just want to welcome everyone to the new Deversus Blog. We’ll be covering many different topics over the next while, ranging from why a custom solution may be right for you, to the latest and greatest tech news. Check back soon for our first (real) article!