blog

What really makes Elexicon valuable to clients is the ability to deliver a lot for a little. When it comes to web programming and development, this can be difficult, because there are so many ways a development project can go wrong. I won’t reveal all our secrets, but here are some of the important lessons I’ve learned that help me ensure Elexicon or our clients don’t waste time or money.

Context is everything

I enjoy developing elegant, clean, programming solutions, but sometimes cutting corners and doing something quick and dirty is fine. No one but me cares about how code looks – they care about how it works. On the other hand, if it’s going to cost the client more for me to maintain my messy code in the future, then it may be better to spend more time to provide a more elegant solution.

The lesson here: Context is everything, and programming in a bubble should be avoided, because the programmer often will know best the questions to ask that could save the client money.

As an example, say a client named Jane Dough needs to import some data into her big important database. She’s considering having Elexicon build her an automated process to do so. At this point, we would want more information. Some questions we would ask would be:

• Is this is one-time data import, or something that would have to happen often?
• How is the data currently formatted?
• How much data is there?
• How long does it take to manually enter a single record?

From the answers to these questions, we could help her determine whether the cost of doing the manual entry would be less than or greater than the cost of building an automated process to do so. Often, there are diminishing returns, where it may cost a great deal to fully automate a system, but to compromise and just partially automate a system is a lot cheaper.

Other examples of common questions I ask myself:

• Should I spend more time today to make this code standardized, or is the chance of reusing it very small?
• Should I spend more time today to make this code maintainable, or will it not be around for very long?
• How tech-savvy is the client? Is it worth spending time on making a system very usable when the client will be able to figure it out anyways?
• Will spending more time on this development project now give me the experience to do it faster in the future?

Don’t reinvent the wheel

This applies to every level of the development process. It may seem obvious, but I still see it violated often.

On a higher level, don’t even think about coding your own shopping cart solution, blog software, or simple content management system. While it might guarantee your job while you have to maintain the behemoth of code you created, it betrays a lack of knowledge of the world around you. Instead of giving clients a system that’s built exactly to spec for a lot of money, you can often buy them a system that goes above and beyond what they want for even less money. It may take time to find the exact solution that fits, but that pales in comparison to the time you would spend implementing and maintaining your own solution.

There are definitely exceptions to this, but during the proposal process the key is to ask yourself: Does the client want something that’s similar to sites all over the internet? If so, someone has probably developed something that will save you time and the client money.

On a lower level, there are plenty of development tasks that can be automated or made easier by libraries. However, I would issue a warning: these concepts should be fully understood before attempting to automate them. I would not use an Object-Relational Mapper (such as Subsonic) if I couldn’t figure out how to code one myself, or use jQuery if I didn’t understand what makes it so powerful. It’s a delicate balance between libraries that save you time on trivial tasks, and those that will take too long to learn and/or restrict your ability to maintain and simplify your code. This is why it’s important to understand the concepts in the first place.

Proper communication is essential

Thankfully, at Elexicon we have a team of project managers who are used to working with both design and development, and who ensure that our lines of communication remain open. Nothing has the potential to save yourself and clients more time, money, and headaches like proper communication, mostly because improper communication can be disastrous. This isn’t just about asking the right questions to be aware of the context. It also comes down to the ability to translate tech-speak into language that the client can understand. Not only will this ensure that clients understand what is being delivered, but it will make your process more transparent and trustworthy. It’s good to be able to answer the client when they ask questions like “Why does this simple development task take 20 hours?” in terms that anyone can understand.

» This entry was posted on Friday, January 15th, 2010 at 10:57 pm and is filed under Business, Development, General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a comment, or trackback from your own site.