New project or not ?
-
You deliver a brand new solution as per spec and business starts using the application. After a week or two they have few suggestions and improvements request. Should that go to issues register or form a part of new project ? As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project. How you deal with such cases ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
virang_21 wrote:
If it ends up in issues register it looks poor on quality of initial product
Sorry but it is BS... Issue is not a bug! There are bugs and there are feature requests - they are different... If someone, somewhere thinks that missing feature is bad reputation, then one is an idiot!!!
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
virang_21 wrote:
If it ends up in issues register it looks poor on quality of initial product
Sorry but it is BS... Issue is not a bug! There are bugs and there are feature requests - they are different... If someone, somewhere thinks that missing feature is bad reputation, then one is an idiot!!!
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
You as a developer know these are new requirements and you suggest so but most of the time project manager don't want to go through the administrative task of spinning up new project and justifying why there needs to be a new project to the project sponsor. They just want to add those new request in issues log for old project and keep that project open and hence slipping the timeline. At the end of the year review these things look bad as upper management looks at those and thinks oh this project was suppose to finish a month ago but due to all those issues it got delayed. Most of the time I accommodate those needs but this time I pushed back saying these are new enhancements and there needs to be separate project for these. Lets see what happens this time.
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
-
You as a developer know these are new requirements and you suggest so but most of the time project manager don't want to go through the administrative task of spinning up new project and justifying why there needs to be a new project to the project sponsor. They just want to add those new request in issues log for old project and keep that project open and hence slipping the timeline. At the end of the year review these things look bad as upper management looks at those and thinks oh this project was suppose to finish a month ago but due to all those issues it got delayed. Most of the time I accommodate those needs but this time I pushed back saying these are new enhancements and there needs to be separate project for these. Lets see what happens this time.
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
So this is all about your internal procedures! If adding an enhancement to an existing requires a new project with all the admin bullshit required by a new project then I can understand your PM wanting to tack it onto an existing project. We simply branch the existing project and continue developing the solution.
Never underestimate the power of human stupidity RAH
-
You as a developer know these are new requirements and you suggest so but most of the time project manager don't want to go through the administrative task of spinning up new project and justifying why there needs to be a new project to the project sponsor. They just want to add those new request in issues log for old project and keep that project open and hence slipping the timeline. At the end of the year review these things look bad as upper management looks at those and thinks oh this project was suppose to finish a month ago but due to all those issues it got delayed. Most of the time I accommodate those needs but this time I pushed back saying these are new enhancements and there needs to be separate project for these. Lets see what happens this time.
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
It sounds the bureaucrats took over your company...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
You deliver a brand new solution as per spec and business starts using the application. After a week or two they have few suggestions and improvements request. Should that go to issues register or form a part of new project ? As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project. How you deal with such cases ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
First, I would consider the financial arrangement with the client: are they paying you well, now ? Client not paying now, after you met the spec and they accepted your code: new contract for maintenance, or new version ... then you go to work.
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it. A few hundred years later another traveler despairing as myself, may mourn the disappearance of what I may have seen, but failed to see.» Claude Levi-Strauss (Tristes Tropiques, 1955)
-
It sounds the bureaucrats took over your company...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Kornfeld Eliyahu Peter wrote:
It sounds as if the bureaucrats took over your companyinsane took over the asylum...
FTFY :)
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
You deliver a brand new solution as per spec and business starts using the application. After a week or two they have few suggestions and improvements request. Should that go to issues register or form a part of new project ? As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project. How you deal with such cases ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
Aside from your internal bureaucracy hell, I would not let them call this any sort of bug. There is one caveat which I use with my own prioritizing: if they took my advice on design, flow, and such, I take some responsibility for the TWEAKS they request - if they ignored my suggestions, then it is back to the end of the line - with a written response. Usually, the ignore-me people are really asking me to rewrite an old application so it looks and feels and works just like the one they use (which makes it a waste of time). If, on the other hand, they listened and let allowed the design to be organized to allow for changes/expansion (often without re-coding a line), then they go to the fast lane. This prioritization acts, by the way, as instructional to the participants and bystanders for future levels of cooperation.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
You deliver a brand new solution as per spec and business starts using the application. After a week or two they have few suggestions and improvements request. Should that go to issues register or form a part of new project ? As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project. How you deal with such cases ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
If the project delivered what was asked for, then the business requesting changes has two option: put the item in an enhancement queue or start a new phase of the project.
-
You deliver a brand new solution as per spec and business starts using the application. After a week or two they have few suggestions and improvements request. Should that go to issues register or form a part of new project ? As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project. How you deal with such cases ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
Sounds more like an enhancement. Improvements and/or suggestions, are enhancements, not issues. Issues are usually bugs or defects found in the original code base that cannot be attributed/linked to a user story or unit of development work. Defects/bugs are spawned from a user story or unit of development work. -- My two cents. Edit: if your team considers enhancements to be new projects, then yes, this is a new project. With that said, I think you are using the term "project" incorrectly. The term "project" should be the High Level application that you are working on, which is run by a Project Manager/team.
-
You deliver a brand new solution as per spec and business starts using the application. After a week or two they have few suggestions and improvements request. Should that go to issues register or form a part of new project ? As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project. How you deal with such cases ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
In our company, we have a 30-day post deployment window where the project team continues to support the project, and all issues - whether they are enhancements or defects - goes to the project team to work on. During this time, the project team is also transitioning the project (through KT sessions) to the maintenance team. After the 30 day window is up, all future issues are entered into the helpdesk system where the maintenance team takes care of them. Any enhancements that are beyond a certain deliverable threshold (i.e. an enhancement that takes more than 80 hours of developer time, or some other measurement) are usually deferred to an "Application version 2" project that will spin up some time in the future.
-
You deliver a brand new solution as per spec and business starts using the application. After a week or two they have few suggestions and improvements request. Should that go to issues register or form a part of new project ? As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project. How you deal with such cases ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
-
You deliver a brand new solution as per spec and business starts using the application. After a week or two they have few suggestions and improvements request. Should that go to issues register or form a part of new project ? As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project. How you deal with such cases ?
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
virang_21 wrote:
As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project. How you deal with such cases ?
As a developer... You mention it "looks poor on quality". Is someone actually tracking this? Does it come up in the developer reviews? In project reviews? Are bonuses directly or indirectly impacted by that? Is there any other way that it objectively impacts something? If the answer to any of those is yes, then as a developer I would scream bloody murder if it was pushed as a bug. If it doesn't then it is more subjective. And as a developer I might ask, but not insist that each be noted in some way as a new feature, even if the tracking system noted it as a bug. Now if there are other criteria in the company where tracking occurs but where it doesn't impact the developer then I still might insist that it not be entered as a bug. If it is used as a metric elsewhere then either it is important or it isn't. If it isn't then why is it being used? If it is then in must reflect something real and not imaginary. Of course the viewpoint outside of the developer, is if there is a customer and a contract then the contract should specify the acceptance criteria. It it was met then additions are extra. If not then it must be corrected. If there is no acceptance criteria then one or more people made a mistake (including the lawyer or lack of one if that was the case.)
