sophistication of the team
-
I work on a development team with a couple other developers, DBA, and a few analysts. My company's philosophy is to satisfy the (internal) customer as completely and quickly as possible, which generally leads to a software development approach that avoids enough requirements gathering, analysis of the problems, management of the project, and enough testing. Do any of you work in a similar environment? How do you go about maximizing the quality of the application when given these constraints? Or, how do you go about eliminating these constraints while convincing management that it's worth it? Or am I just being selfish and wishing for a more sophisticated development environment where it is not needed?
I work in a progressive start-up that's like this. I was given a whole 2 weeks to design a massive N-tier application with a strict set of requirements that changed to allow for more flexibility - how I wanted to do the application in the first place - a few months after that. It was hacked to allow for such because of time constraints and now suffers even worse as we add more and more to it. We also have several other products that my CEO - who programmed over 15 years ago and not again until recently :eek: - writing AutoCAD plugins and doesn't think we need to test them. It's been a complete nightmare. I've gone through several knowledgable interns (like Nick Parker) and have retained one who hasn't graduated yet. I also have one other compitent programmer (Tom Larsen, who you may see from time to time here). The rest of Industrial Engineers (IEs) with entry-level coding skills (they've improved, though) and don't have the mindset (either learned or taught) for efficient code. Fortunately - being such a small company - we have the ability to basically say how it is (especially the Exec Dir. of R&D - an IE since we make software for IEs - and me, the Dir. of Tech.). Why, just today we told our CEO that his add-ins have to go through testing and a release cycle, not just shipped out on a whim (plus it takes me a while to hack the AutoCAD OEM installation with what's needed using Orca), especially to potential customers who haven't even given us a PO! Requirements change weekly (normal, but often these requirements are mutually exclusive to implement), our testing is short and sometimes non-existent since we "progressive", and forget proper management of the projects - there's just no time and definitely no manpower. Okay, a little raving in there, but you asked. :) If you have the respect of your management team (i.e., they respect their knowledge), you might try telling them that these things are just necessary. If that doesn't work, try spinning that customers these days don't accept buggy software. This works especially well if any POs are being lost because potential customers just aren't buying. You just have to speak whatever lingo they speak so you can make them see it your way in their terms.
Microsoft MVP, Visual C#
-
Mike Hodnick wrote: My company's philosophy is to satisfy the (internal) customer as completely and quickly as possible, which generally leads to a software development approach that avoids enough requirements gathering, analysis of the problems, management of the project, and enough testing. Are you sure that the customer is satisfied with a buggy, ill-implemented software, which doesn't fully address requirements? Mike Hodnick wrote: Do any of you work in a similar environment? How do you go about maximizing the quality of the application when given these constraints? Or, how do you go about eliminating these constraints while convincing management that it's worth it? Or am I just being selfish and wishing for a more sophisticated development environment where it is not needed? Yes, I did. Actually, my own company was like that around 7 years ago. It was a shame. What we did was a slow work, that started with proper version control, automated build, bug control - Bugzilla, QA testing. All step by step. Due to technical difficulties my previous signature, "I see dumb people" will be off until further notice. Too many people were thinking I was talking about them... :sigh:
Daniel Turini wrote: Are you sure that the customer is satisfied with a buggy, ill-implemented software, which doesn't fully address requirements? No, the customer tends to receive software that contains few bugs and satisfies their needs, but I think that the process in which we provide it is disorganized. Let me put it this way: there is a cloud of impending doom over each team member's head because nobody has confidence that the project will succeed because not enough groundwork (e.g. requirements gathering) has been done and they need to scramble to get information at the end, or because not enough planning (e.g. project management) is happening and expectations and progress is not being communicated. I think I'm answering my own questions here... thanks to your question :-D I'd like to think that improving our processes will not necessarily take more time in a project. In fact, introducing more organization could speed up projects by preventing unnecessary scrambling at the end.
-
I work on a development team with a couple other developers, DBA, and a few analysts. My company's philosophy is to satisfy the (internal) customer as completely and quickly as possible, which generally leads to a software development approach that avoids enough requirements gathering, analysis of the problems, management of the project, and enough testing. Do any of you work in a similar environment? How do you go about maximizing the quality of the application when given these constraints? Or, how do you go about eliminating these constraints while convincing management that it's worth it? Or am I just being selfish and wishing for a more sophisticated development environment where it is not needed?
I work alone but I'm heavily supervised. Sometimes this means that I have to release something that's not tested and doesn't even work properly (crashes often) because of unreasonable demands. And then there's complaints about software quality :( But I guess this is my own private hell. "To his dog, every man is Napoleon"
-
Daniel Turini wrote: Are you sure that the customer is satisfied with a buggy, ill-implemented software, which doesn't fully address requirements? No, the customer tends to receive software that contains few bugs and satisfies their needs, but I think that the process in which we provide it is disorganized. Let me put it this way: there is a cloud of impending doom over each team member's head because nobody has confidence that the project will succeed because not enough groundwork (e.g. requirements gathering) has been done and they need to scramble to get information at the end, or because not enough planning (e.g. project management) is happening and expectations and progress is not being communicated. I think I'm answering my own questions here... thanks to your question :-D I'd like to think that improving our processes will not necessarily take more time in a project. In fact, introducing more organization could speed up projects by preventing unnecessary scrambling at the end.
Mike Hodnick wrote: I think I'm answering my own questions here... thanks to your question I'm glad you understood my intention :) Due to technical difficulties my previous signature, "I see dumb people" will be off until further notice. Too many people were thinking I was talking about them... :sigh:
-
I work on a development team with a couple other developers, DBA, and a few analysts. My company's philosophy is to satisfy the (internal) customer as completely and quickly as possible, which generally leads to a software development approach that avoids enough requirements gathering, analysis of the problems, management of the project, and enough testing. Do any of you work in a similar environment? How do you go about maximizing the quality of the application when given these constraints? Or, how do you go about eliminating these constraints while convincing management that it's worth it? Or am I just being selfish and wishing for a more sophisticated development environment where it is not needed?
-
I work on a development team with a couple other developers, DBA, and a few analysts. My company's philosophy is to satisfy the (internal) customer as completely and quickly as possible, which generally leads to a software development approach that avoids enough requirements gathering, analysis of the problems, management of the project, and enough testing. Do any of you work in a similar environment? How do you go about maximizing the quality of the application when given these constraints? Or, how do you go about eliminating these constraints while convincing management that it's worth it? Or am I just being selfish and wishing for a more sophisticated development environment where it is not needed?
I tend to find, because the projects I work on are not particularily complex not much planning is needed. However the requirements for even small projects need to be accurate and documented as not doing so produces software that is buggy and useless. One of the worst working days I've had was when a colleague working in another part of the business told me that the web application I'd spent months building for them was not only useless for the job it was required for but actually made the persons job harder. This situation arose because no-one sat down and asked that person what they wanted/needed the app to do. If I had a better memory I would remember more.
-
I work on a development team with a couple other developers, DBA, and a few analysts. My company's philosophy is to satisfy the (internal) customer as completely and quickly as possible, which generally leads to a software development approach that avoids enough requirements gathering, analysis of the problems, management of the project, and enough testing. Do any of you work in a similar environment? How do you go about maximizing the quality of the application when given these constraints? Or, how do you go about eliminating these constraints while convincing management that it's worth it? Or am I just being selfish and wishing for a more sophisticated development environment where it is not needed?
This is a very common problem. It stems from management not understanding the development process and the need to manage such processes. They do not see the advantages of such methodology. It seems to be more prominent in small organisations in my experience. I have been forced to take it upon myself to manage the part of the project that I am working on. One piece of advise is to notify your managers as soon as you see any problems or potential problems or any risks. This way you can say that they were informed if any "blame-storming" occurs. Ant.
-
I work on a development team with a couple other developers, DBA, and a few analysts. My company's philosophy is to satisfy the (internal) customer as completely and quickly as possible, which generally leads to a software development approach that avoids enough requirements gathering, analysis of the problems, management of the project, and enough testing. Do any of you work in a similar environment? How do you go about maximizing the quality of the application when given these constraints? Or, how do you go about eliminating these constraints while convincing management that it's worth it? Or am I just being selfish and wishing for a more sophisticated development environment where it is not needed?
From what I've dealt with, the most important step is to get a solid automated build/test/release cycle. It has eliminated the most problems/bugs with the product. I've always found requirements gathering a complex process that often overlooks the most important part. The relationship with the customer. I've gone from working with loose requirements to complex problems with a good relationship with the customer, which worked really well, because we had the freedom to make technical recomendations and there was an actual debate on the features until we locked down something that was implementable and we could move forward. In another group we had to deal with a customer that wanted to dictate the requirements to us so we took them down and implemented a very poor quality product. Management came up with a fix by introducing "solid" requirements gathering. This produced massive documents that nobody read and was the most miserable phase for everybody. At this point we hired a really good architect and setup a system where we started inital development when the design document hit 20% complete, but we had a solid build/test/release cycle, we got feedback to the customer in a managed way and worked on building a solid working relationship with the customer and things improved greatly. I'm working in a new company now that is using silo development with multiple projects per developer with chaotic development processes. In my silo I have automated builds for all my projects, because that is the way I develop best, and I'm starting to educate others on the team as well as management, when they see that I have fewer bugs in my code, which translates directly into a higher level of productivity.
If you don't kill me you will only make me stronger That and a cup of coffee will get you 2 cups of coffee
-
I work on a development team with a couple other developers, DBA, and a few analysts. My company's philosophy is to satisfy the (internal) customer as completely and quickly as possible, which generally leads to a software development approach that avoids enough requirements gathering, analysis of the problems, management of the project, and enough testing. Do any of you work in a similar environment? How do you go about maximizing the quality of the application when given these constraints? Or, how do you go about eliminating these constraints while convincing management that it's worth it? Or am I just being selfish and wishing for a more sophisticated development environment where it is not needed?
What you describe is pretty much the norm in our business. Nobody ever really gives you the time to do things "the right way", and one of my little areas of expertise in life is writing about how developers can cope with that and get the best product possible out the door given the prevailing reality. There are a number of articles from columns I've written in the past that you might find useful. Take a look here[^], in particular the columns Programming in the Real World and Pro Developer (the latter can also be found here on CP). Hope this helps, Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
-
I work on a development team with a couple other developers, DBA, and a few analysts. My company's philosophy is to satisfy the (internal) customer as completely and quickly as possible, which generally leads to a software development approach that avoids enough requirements gathering, analysis of the problems, management of the project, and enough testing. Do any of you work in a similar environment? How do you go about maximizing the quality of the application when given these constraints? Or, how do you go about eliminating these constraints while convincing management that it's worth it? Or am I just being selfish and wishing for a more sophisticated development environment where it is not needed?
Mike, there is a great book that addresses these issues: Software For Your Head Marcie