Publication Date: 6/11/2010 5:38:16 AM
When your software breaks, how quickly do you expect the programmer to respond to your request for assistance?
Okay, that’s probably too broad. We both know that it depends on how broken it is.
The software I build for my customers is an integral part of their business. It might be their money scoop. Or it might run their day-to-day operation. Regardless, if it isn’t working at all, it affects their bottom line pretty quickly.
On the other hand, if it is minor bug that only affects a limited number of transactions, it probably isn’t an emergency.
Assuming it is ...
Publication Date: 3/8/2010 6:39:17 AM
I have unhappy news for you. Your design will never be perfect.
This can be very frustrating to some people. (Probably perfectionist people like me.) They We will spend days/weeks/months agonizing over a design trying to make it perfect.
But it can never be perfect. There will always be trade-offs. Some choices will make your app more maintainable. Others will make it perform better. Some choices will make your app easier to use. Others will make it easier to code.
In one recent design meeting, we focused on a decision between ease of data retrieval and a more descriptive data ...
Publication Date: 2/15/2010 6:38:17 AM
Whenever I’ve heard people talk about the importance of a single point of contact for communication between the developer and the “customer”, I’ve thought this was primarily to protect team members from unnecessary emails and meetings. But what I’ve come to realize is how important this is to project health generally, for a couple of reasons:
If only one person is giving the programmer feedback, they are less likely to get conflicting messages about how things should work.
Less communication about the communication
As a programmer on the outside of an organization, I often can’t tell who will ...
Publication Date: 1/18/2010 9:06:43 PM
Most programmers who have been around a few years can tell you horror stories about a software project they worked on. The stories are varied, but most of them involve an “unreasonable” customer who kept changing their minds, and the project suffered from lots of rework and frustration, or perhaps didn’t even get finished. (Even I have a story like that.)
Which is why programmers are often surprised to learn that I don’t charge by the hour. They’ll ask, “Aren’t you worried that the customer will change their mind repeatedly and you’ll lose money?”
Most customers aren’t ...
Publication Date: 10/5/2009 6:56:33 AM
Software estimates can be tricky. One challenge is remembering what to include. When people put together their estimates, they usually focus on the features but often forget some critical pieces that aren’t functionality specific.
You might think that as a customer you don’t need to concern yourself with this. To a degree you are correct. But if your software roll-out has dependencies that make hitting target dates critical, you’ll want to feel confident that the estimates are accurate. Also, some developers who charge on an hourly basis can low-ball projects by providing estimates that exclude these tasks. It will be ...
Top 5 Programmers to Avoid
What everyone should know about bugs
How to tell if an estimate sucks
The Secret to Building a Crappy User Interface
The Problem with Selecting the Lowest Bidder
5 Ways to Control Software Development Costs
Avonelle has been a pleasure to work with. Working with someone that you know will always deliver is tremendous.
Mark McNamee @ Renewal by Andersen
Copyright © 2013 Avonelle Lovhaug. All Rights Reserved.
Sitefinity ASP.NET CMS