Development process models… usability compromise

It is very popular now to speak about development process models in software development. I have feeling that it became something like style of developing, and even some companies have created their own standards based on some well known models. Often in this style hunting process people forgetting about the main goal of company. Web development company, as every trade company, should care more about products success and the annual income itself and not on that how it is going on with the Paper works and are developers follow the rules of defined by company low : “the only Model of working”. I don’t mean that paper work is spending time and money, it is very important to have documentation on everything and everywhere, but at least we should be as flexible as different are our problems and products.

I can understand the architects and product leads who wants to have full documents and artifacts, the reasons are very strong, when everything that doing product managers, developers, and architects is written down and it is written in predefined templates, it is very ease to track everything considering project developing and product future, but in other hand first requirements of any product are budget, deadline, and quality, and then only strongly documented, but as shows experience technical and none technical documenting is may be the most expensive cycle in whole development process… so where is the Compromise…

I’ll try to explain some points of my opinion on development process model compromise

I think first of all well and fully documented should be only that products who already have got his place under the Sun, of course here some PM can be blame on me, but … “selavi” not every project that was born in someone brain and started development has at least succeed finished implementation.

second: there should be at least two different models described, one for complete new product second for new releases, i don’t think that it is good idea when you can pass some points of the model or start with the middle of described model according to your needs.

The man who suggesting concrete model should be responsible for success or fail of it, means if he project was failed there can be only fail of planing, good plan- plan to do, in that case model suggester will be more flexible while thinking about selecting model for concrete product.

It is not secret that the heaviest part of whole development process is planing and creating product skeleton, so i think it is better to pay more attention on that points, even in very first steps of product development process discuss more about which modules and technologies should be used product to get functional requirement that needed.

On the first pages of product documentation (vision …) should be reports of every team participants, product managers, marketing department, architects, developers …, other external modules delegates if exists…,

On the process of implementing should not be any big documentation in tasks of developers, but should be an strong requirement that every peace of code should be well commented by them, supervisors and architects should care about revisions of comments also.

of course the topic is larger then i can put in post, and topic itself is very interesting so i guess we will have hard discussions about it later on…