Custom Software

Custom programming is a delicate balancing act between quality, cost, and development time. Our team has the experience and communication skills needed to help plan, prioritize, implement, and maintain a solution that meets your specific needs. Our custom programming jobs have covered a lot of ground:

ASP.NET website to augment a legacy Java socket-based messaging system

Ruby on Rails website to replace an in-house Access database

C# command line application to aggregate reports from a third-party server

To determine a programming project we first roughly define your needs, determine if we can reasonably meet those needs, and then develop a more detailed specification of work. Once we have the specification, we’ll put together a detailed estimate with time and cost information. If you need some consultation to help define your needs (we do this for many clients) then that is available, and would be billable work.

We estimate in ranges (for example, 1-3 hours), usually coming in around the average of the range. We record our time within our project management software, keep the client updated on project status and time spent, and charge for actual time recorded (even if less than the original estimate). Our standard pricing is $100/hour – with discounts available for large blocks of hours and to purchasers of other Acceleration services. For more information, please contact us.

There are many ways to produce software. Over the years of producing client and internal projects, we've tried out many different techniques. We have established guidelines to follow that have made us better developers.

Use version control

A version control system keeps track of all source code, logging each change, who changed it, when they changed it, and why they changed it. This logging is invaluable. We've used Subversion, Darcs, and Git, each having their own set of pros and cons.

With version control, we can look up who last changed a piece of code and read the commit message to see why they did it (more on this later). Version control systems help merge different changes to a file, so we can work in parallel with confidence that our work won't be lost. We use the branching features to make large, multi-week changes to code without sacrificing the ability to make quick bug fixes to the production code. We use tagging features to take snapshots so we know exactly what state of code is running on the live site at any time.

Use a ticket system

Ticket systems are a vital project management tool to keep development running smoothly. Years ago we wrote our own ticket system, then realized we could get a vastly better product using one of the many free options. We settled on Trac. Trac helps us assign tasks to our staff, sends email notifications so we know when something has changed, and serves as a clearing house for task-related information that was previously locked up in someone's email. We use the system to keep up with low-priority tasks that would previously get forgotten in old email. It also helps us communicate, using ticket comments to ask and answer questions without needing to disturb each other.

Keep track of your time

Time tracking is a key to making decent estimates. You need a feedback cycle to see how accurate your estimates were, and adjust from there. Time tracking is essential to accurately generating billable hours. Even on non-billable work, when the financial motive is gone, it's important to get a sense of how long a task will take you.

Make your version control and ticket system talk to each other

The unnecessary overhead of a ticket system can be eliminated completely by linking it to your version control. Every version control system provides hooks for you to run scripts after every commit. We use that feature to automatically add comments and time to tickets from the commit message. This gives developers one easy place to record their notes, and encourages good detailed commit messages.

Write good commit messages

Commit messages is the way to tell the future what you were thinking when you changed this code.

Take the extra time and ask yourself:

Does the commit message give you (and everyone else) a reasonable idea of what has actually changed?

Does the commit message use unidentified pronouns?

Do you reference a relevant ticket number?

Do your commit messages contain enough nouns such that you could search logs in a month and find these commits?

If you are debugging this change 2 years from now at 11:45PM, will it make you angry?

Write human-readable code

Use descriptive names. The short-term benefit of using short names is drastically outweighed by the long-term maintenance cost you pay every time you come back to a piece of code and wonder what the variable "A1" has in it. With the exception of looping variables, long names are better. Use editors that support code-completion, so length and spelling isn't an issue. With descriptive names, you don't need to comment as much. Comments quickly become stale and inaccurate, but your code will always represent the current process.

Simpler is better

Log. Log a lot.

Get a second opinion

Code reviews and team programming are easy ways to improve code and reduce defects. After writing a section of code, print it out and talk about it over lunch. When fighting fires in emergency situations, having someone there helps prevent panic reactions. When writing new code, the extra person is an automatic sanity check. Full on pair programming isn't always required, but can really help when working on critical code (eg: anything involving money). Short of pair programming is a quick impromptu consult, where you lay out what you're about to code and get a second opinion. Frequently the other person can see a simpler solution because they haven't been focusing on the problem for an hour, and the process of explaining your plan can provide insight.

Over the course of our consulting work, we've been exposed to many different technologies and have had the opportunity to work with both proprietary and open source systems. This experience has provided a practical big-picture perspective on the tools and techniques available.

Using such a wide variety of tools exposes us to new and often better ways to solve common problems and improves the quality of our code across all languages. We pick the best techniques out of proprietary and open-source systems, using the best of both worlds. It is easy to fall into the rut of "good enough" code; doing so can be a costly mistake in our fast-moving industry.

Our wide experience also allows us to compare the strengths and weaknesses of different tools and reasonably choose the best tool for the job. Sometimes those tools might be a set of Ruby scripts designed to be edited by the client, an ASP.NET application and a few windows services, or even a Lisp-driven website backed by PostgreSQL.

We've worked with these specific technologies and programming platforms:

Having a hard time finding someone to help you work with Crystal Reports? Our programmers have been thrown in to many different situations where we just had to dig in and find a way to a solution. We know how to get the most out of the system - fast results and beautiful formatting.

Our open source strategy is simple:

Save time and money by building on top of existing open-source systems where possible, and contribute back to the community when doing so has no significant downside.

We have used this strategy with great success on a variety of projects, believing that most of the value in a piece of software is derived from the humans creating, maintaining, and using the program and the data therein.

Your data is protected and never shared. In our experience, when trading source code with other organizations, the value of the actual files has consistently been overestimated.

We always look at things on a case-by-case basis, trying to ensure that our client's interests are being preserved. If you have questions or concerns, ask us about it!

The Acceleration development team is a small group of dedicated professionals who take pride in creating quality software and solving real-world problems.

Every member of our team has been with us for at least eight years, making our internal communication and processes smooth and well-practiced. We do not employ a sales staff, there are no team members fighting for sales quotas and commissions. When a proposal is requested, the team that would be building the site is the same team providing the information and estimate included in the proposal. We are straightforward about our prices and processes, believing in the team and policies we have put together over the years. You will not find another company that would care more about the product they would build for you or your satisfaction in it. And, with a minimum of 10 years/person of professional experience creating websites and applications, we have the knowledge and flexibility to meet your needs.

Over the years, we've done large and small consulting jobs, produced several hosted products, and worked in dozens and dozens of languages and environments. Our clients have included San Francisco startups, Melrose artisans, UF Students and Faculty, and small businesses just trying to get online.

We also enjoy working with and contributing to open source projects and have been steadily adopting more into our systems since 2005.

Creating software is a difficult task. The goals of a program can be hard to specify and can change as rapidly as your business. With shifting destinations and a myriad of possible implementations we have adopted some procedures and tools to keep the process on track and running smoothly.

As well as developers, we are also consultants. We perform a thorough analysis of the goals and proposed benefits the program is supposed to provide in order to ensure the client will get the value they seek-- sometimes it turns out software isn't the answer. This analysis requires a lot of questions and answers, and is also used to determine effective communication channels early on.

We practice a variant of the Agile Methodology: try to get a working prototype early on, which is then used to guide further development.

Consult with client to determine needs and generate a rough specification for what should be implemented.

Break the spec into small work items and estimate each one. The aggregate estimate is then presented and while each item has lots of variability the sum provides a good guide for the cost of a project.

Implement a prototype based on the work items. We use software configuration management tools to record every code change, link each change to a work item, and record time spent. This process builds up a database of useful information covering nearly all aspects of the project.

Consult with the client to see how well this meets their needs. Cycle back around incorporating changes.