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 is a rare IT professional who can communicate with business users on a level they can understand, and who can recommend creative technical solutions that are in line with the business goals and the business budget. Avonelle is conscientious not only about meeting deadlines, but also exceeding her customers expectations around quality software while providing superior customer service. Avonelle is an inspiration to me.
Valerie Vogt, Director of IT Advisory Services @ Inetium
Copyright © 2013 Avonelle Lovhaug. All Rights Reserved.
Sitefinity ASP.NET CMS