Publication Date: 5/8/2009 7:54:28 AM
Most independent programmers have a fear of scope creep. Actually that’s not completely true. Most have a fear of scope creep they won’t be paid for. For those who are doing a fixed bid project, the fear is that expanding scope will eat away at any profit until they are making about $1.30/hour. Yikes.
To compensate, some programmers get very aggressive about delineating project scope. They become militant when even a small feature change is suggested. And I have a lot of sympathy for that position.
But I don’t share it.
Look, everyone I know who has been in ...
Publication Date: 4/30/2009 8:14:34 AM
All I wanted to do was to create some calendar entries. A date, some times, and a description. Not too tough.
Except the person who created the user interface has clearly not spent a lot of time actually doing this task. Take a look at the form:
Now consider for a moment how annoying it is to enter start and end times on this form. It always defaults to “01:00 AM”, which of course is NEVER the start time for one of my appointments. So I must always change the first drop down value. And if the appointment starts on ...
Publication Date: 4/24/2009 12:58:12 PM
Everyone hates documentation. It is either boring or it doesn’t answer provide the needed answers. Many programmers agree that documentation is critical when they are taking over a project for someone else, and think it is completely unimportant when they need to create it themselves.
So as a customer: what documentation should you expect or require from your programmer?
Every situation is different, but here are some documents you may want to consider requesting:
This is the specification that was (usually) created before the programming began. It can include functional specifications, wireframes, screen mockups, user stores, UML diagrams, ...
Publication Date: 4/22/2009 6:38:16 AM
Good projects (and by “good” I mean “successful” of course) always have a defined objective. Everyone knows the goal, and everyone stays focused on that goal throughout the project.
Also important in a good/successful project is understanding the project sponsor’s values. For example, some customers place a high value on source code portability – the ability to easily take the code to any vendor. Others may prioritize completing the project as quickly as possible. In the case of the former, using a third party component might not be appropriate, but for the second customer this might make a lot of ...
Publication Date: 4/17/2009 8:41:41 AM
If you plan on enjoying your evening, I recommend that you do not ram a deer with your car. Really. Truly.
I did not follow that advice. Last weekend as we drove home from a family gathering, a deer jumped into the road directly in front of the car.
There was nothing I could do. There was not enough time to stop. Swerving would have put me in the lane of oncoming traffic, or the ditch. So I hit the deer.
As you can imagine, the evening went downhill from there. I won’t bore you with all the details: the ...
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