I just discovered this Video broadcasting platform - MyDeo. This is like a private YouTube. The problem is I got a problem with their account creation process.
After emailing their customer support team, I immediately got a reply. Obviously I created a "Corporate Account" this probably raises the importance of the incoming requests. However, they nonetheless reacted within minutes and even called me to resolve the problem.
I did not even had the time to consider trying another such service provider. It is taking me longer to write this post than it tool them to help me. That is good customer service. You might want to check them out if you need to share videos in a private manner.
So maybe as Jason is right when he says that T&M should mean Time for Money but I believe that T&M can also mean Time and Money... With the little time it took them to help me, they are getting closer to get my money. ;-)
Showing posts with label quality. Show all posts
Showing posts with label quality. Show all posts
Friday, 11 July 2008
Saturday, 7 June 2008
FIXME and TODO
Part of our development process is the need to show your code - by the mean of patch/diff files - on a daily (aka frequent) basis. Doing so, you are more often than not showcasing work in progress.
There are several benefits in enquiring frequent feedback on your implementation:
If you do not want to create tasks and estimates for each of these you have to keep them visible to all team members at all time. Some IDEs offer the meachanism to create warning in the build log when they encounters certain keywords, this does the trick nicely.
When this is not possible a simple: cat logfile | grep 'TODO' part of your build process will do the trick.
It also appears to be a good idea to ask your developpers to put their name beside their TODOs this way you will know who to talk to in two months when you will be wondering how to get rid of the TODOs.
There are several benefits in enquiring frequent feedback on your implementation:
- optimizes design quality
- reduces potential waste caused by misunderstanding sooner than later
- promotes top-down software development
If you do not want to create tasks and estimates for each of these you have to keep them visible to all team members at all time. Some IDEs offer the meachanism to create warning in the build log when they encounters certain keywords, this does the trick nicely.
When this is not possible a simple: cat logfile | grep 'TODO' part of your build process will do the trick.
It also appears to be a good idea to ask your developpers to put their name beside their TODOs this way you will know who to talk to in two months when you will be wondering how to get rid of the TODOs.
Sunday, 25 May 2008
Checklists in the real world...
This afternoon I understood the real reasons why checklists are important.
I flew a small Cessna-172 Golf Bravo Golf Zulu. Although I have been a believer in checklists - even though their use is challenging in the software world - I realized how critical using them can be and how useful they ought to be when comes time to inspect a plane before to take off.
No, my pilot was not holding a piece of paper and a pen, checking things off a list. He did not even know the exact number of items on the list. He just did the inspection required by this process with our possible death as a consequence of a checklist failure. This was enough for him to do it diligently. Thanks Marc!
We have many occasions to use checklists when creating software products, there are indeed plenty review processes at all phases of the job:
After today's experience, I believe that the answer to checklist success lies in a couple factors:
To help with applying checklist, imagine that you are reviewing a component of a plane that you will fly, I can assure you that you will likely do the right thing!
To get a feel of my flight load this into Google Earth, select it and hit play.
I flew a small Cessna-172 Golf Bravo Golf Zulu. Although I have been a believer in checklists - even though their use is challenging in the software world - I realized how critical using them can be and how useful they ought to be when comes time to inspect a plane before to take off.
No, my pilot was not holding a piece of paper and a pen, checking things off a list. He did not even know the exact number of items on the list. He just did the inspection required by this process with our possible death as a consequence of a checklist failure. This was enough for him to do it diligently. Thanks Marc!
We have many occasions to use checklists when creating software products, there are indeed plenty review processes at all phases of the job:
- Specification
- Estimation
- Architecture and Design
- Code
- QA
- etc...
After today's experience, I believe that the answer to checklist success lies in a couple factors:
- Professionalism
Understand your role when reviewing and the impact you can have on the overall quality and risk mitigation.
- Agility
Assuming professionalism, you do not need to tick things off a list to claim that you have applied a check list. In doubt, go back to it when needed, revisit the checklist to confirm your understanding of the checklist.Next time you are provided with a checklist, do not necessarily think that you have to print it or tick things off of it to use it, be smart and agile enough so you can perform the review process with diligence.
To help with applying checklist, imagine that you are reviewing a component of a plane that you will fly, I can assure you that you will likely do the right thing!
To get a feel of my flight load this into Google Earth, select it and hit play.
Friday, 16 May 2008
Measuring Project Success
We probably have in general more than 50 projects going on simultaneously. This is a lot of projects. They start, they end, we move on.
How do we know that we have succeeded?
It ultimately comes down to one or two factors, these two questions are asked in our customer satisfaction survey sent out at the end of every projects:
When our customer are telling us that they would do business with us again and/or that they would recommend us we are happy.
I was reading this article about Measuring the success of a project and although the suggested metrics make sense, they neglected to consider the fundamental questions above and focused on secondary aspects (schedule, scope, budget, market acceptance, customer sat in terms of # of complaints).
In a service company, getting repeat business is what makes you successful even though you could not respect the schedule at 100% or meet the budgetary expectations.
Getting repeat business especially after though times implies trust and this is a warm feeling.
How do we know that we have succeeded?
It ultimately comes down to one or two factors, these two questions are asked in our customer satisfaction survey sent out at the end of every projects:
- Would you do business with us again?
- Would you recommend us?
When our customer are telling us that they would do business with us again and/or that they would recommend us we are happy.
I was reading this article about Measuring the success of a project and although the suggested metrics make sense, they neglected to consider the fundamental questions above and focused on secondary aspects (schedule, scope, budget, market acceptance, customer sat in terms of # of complaints).
In a service company, getting repeat business is what makes you successful even though you could not respect the schedule at 100% or meet the budgetary expectations.
Getting repeat business especially after though times implies trust and this is a warm feeling.
Thursday, 3 April 2008
Test Driven Development
One of my esteemed college has been talking this week about the importance to train people on the Top 10 Bug Patterns. I thought this was a very interesting idea that we should pursue.
After all it is not that complicated to inject these common defects in a dummy application and let people chase them.
However, this led me to think about what can we do to avoid these bugs in the first place, and then looking at them one at a time, it became clearer that most of them (if not all) can be prevented using Test Driven Development.
I believe that having strong debugging skills in a team is a must but I too believe strongly that there is no better debugging strategy than one that requires from you that you do not let them get into the code base in the first place.
Obviously, TDD does not apply when you are provided a broken application to work with but this is not the normal case, we generally start from scratch.
I would not sacrifice our XUnit testing training in favor of a debugging training... Thanks Didier for the seed!
After all it is not that complicated to inject these common defects in a dummy application and let people chase them.
However, this led me to think about what can we do to avoid these bugs in the first place, and then looking at them one at a time, it became clearer that most of them (if not all) can be prevented using Test Driven Development.
I believe that having strong debugging skills in a team is a must but I too believe strongly that there is no better debugging strategy than one that requires from you that you do not let them get into the code base in the first place.
Obviously, TDD does not apply when you are provided a broken application to work with but this is not the normal case, we generally start from scratch.
I would not sacrifice our XUnit testing training in favor of a debugging training... Thanks Didier for the seed!
Subscribe to:
Posts (Atom)
Posts
