what's ISV?: Independent Software Vendor... so go on reading...
I'm in the search for a number of rules I would like to be applied to the development of a specific software solution my company is about to begin. I know that not all aspects of designing, coding and publishing of a software solution have specific and clear methods of dealing with. However, in the real world, rules should be set so that:
- all people in the same department work the same way,
- people of different departments know when and what to expect from other departments,
- people of different departments trust each other
I know that what I have in mind is not the conception of all time! I also, however, know that these concepts are very difficult to apply in a small ISV, like the company I work for.
1. Working the same waySimple enough? Simply all people agree with that all people of the same team should work the same way. I would like to go a litter further and set some specific rules:
- naming variables the same way (also known as hungarian notation - don't know why!?): for instance, starting all string variables with an 's', all integers with an 'i' etc, and all objects with the datatype name of them (Dataset_Orders, Form_Main, SqlDataAdapter_GetOrders). It's easier to read somebody elses code this way.
- ... I'm in the search for other rules here!
2. MilestonesHere how it goes:
Somebody has a great idea and hopefully all folks agree. The idea is great because we already found people who are interested and we are definately capable of transforming the idea into a solution of high quality.
Funding! We can't wait for a year to have the first version since we need some money from the first people who express their interest in our product. Well, ok! It's not a complete product yet but our skillful sales guy already sold it!!!
Software development terms: a proper software development procedure requires alpha and beta version of a product, testing and other stuff.
So, when should we set the date for our alpha, beta and first final version to be ready? What features should we implement for that first version? Should we search for customers that will do the beta-testing?
3. Trust among departments - TransparencyEric Sink talked about transparency in company procedures to gain the customers trust (see
'Tenets of Transparency' in MSDN). I would like to use this idea and talk about transparency among departments of a single company.
I definately get my pay-check every month and somebody wouldn't care what's going on afterwards. However, I'm always concerned about the progress of my career. So I try to do all I can to improve my skills and to do things great, so that each project I'm dealing with, on behalf of the company I work for, is of maximum quality.
What if, however, somebody else doesn't do the same? What if the sales guy is of questionable value and what if my boss isn't good enough to see that! What if she thinks the same way about me! Wouldn't her incompetence put the bonus my boss promised me at risk?
- I would like to know who, when and what is to be done in order for the overall project to go well.
- I would like to feel comfortable when I have to stay late in the evening at work in order to have the next version on time!
Share
Comments [0]