I am the software process development designer and champion. That is not my main job, but the duty has fallen to me, and I rather like the work since it's letting me apply a lot of knowledge that I've gained over my career.
There are places in the process that are known weak points. I identified some of those weak points in the process and made it really clear that these are things that need to be addressed-- the two major ones at any rate-- specifically because I've seen the same problems over and over in a bunch of different places. And lo and behold, those things were problems, and were a huge pain in the ass.
Part of the issue was that we were given a feature list to implement and a hard deadline by which to release. In order to do that, some of the "details" of the process were thrown out the window, like design, code reviews, documentation... little niggly details like that. At the time I protested but was overridden.
Well, the corporate Software Quality Czar has now taken an interest in the project, and is now starting to ask questions that are leading into "why wasn't your software development process followed?". She will be coming out here in a couple of weeks for several days.
Thing is, I will answer that question with honesty and very little tact.
Our software process-- at least from a high level-- is pretty simple and standard:
1.) determine the feature or operation to be designed
2.) analyze it and build a set of requirements
3.) create a design based on those requirements
4.) code/debug to the design
5.) test to the requirements (validation)
6.) release the code
What actually happens in crisis mode:
1.) get the name of a feature desired
2.) get a vague description of how it kinda sorta should work
3.) guess the rest
4.) code something
5.) show it to people
6.) have them clarify that it wasn't what they wanted at all, and these things need to change
6a.) argue a lot
7.) repeat steps 4-6 until it seems to satisfy everyone
8.) show it to marketing who wants to change more stuff
9.) fix all the marketing stuff
10.) send it to release
11.) get some last-minute requests from somewhere to make some changes
12.) make the changes
13.) send it to release again, hope it takes this time
One of my current projects (though I'm currently stuck in #12) is writing up the process review. Some of the big issues:
a.) We did not get requirements up front because "it's too difficult". Yes, it is difficult, but it has to be done. What we ended up doing was developing requirements by elimination, the "you build it and we'll tell you what we don't like" method. That way lies madness: one of the #11-style issues that I'm having to do is move a control back to where it was because the change that was requested turned out to be something that somebody didn't like.
What I will say is that we tried. For one particular feature, I even designed a mockup of the user interface and documented the operation, and we had hours and hours of meetings and discussions on how it should look, what needed to change, and so on. What we finally ended up with... well, let's just say that the path was not smooth.
b.) The section where we review the operation has a big note attached that says This should not be seen as an opportunity to make design changes or add new features, which is exactly what it turned into.*
I understand why this happened. The two guys (yet another problem) that are deciding on the look, feel, and function both work in much the same way, in that they get stimulated when they have an actual working prototype in front of them, and it opens up new ways of thinking for them. The consider things that they haven't before. I understand that, and I think it is something that needs to stay in the process, but be moved much earlier in the process. Unfortunately, I don't know how to do this rapid prototyping with the software in the state it is currently.
*This is the way that the software "has always been done" in the company-- prior to my hire. It also explains why the software is in the state it's in: it was originally written in 1987, and has been added onto, evolving like coral. The core code was written for DOS.
The entire development team is behind a complete ground-up redesign. Marketing is not, because it offers no marketable value like shiny new features do. They can sell shiny, they can't sell ground-up redesign.
Management likes money. Marketing drives sales, which brings in money. Software development costs money.
What I need is to develop some shiny presentation that can convince the management and marketing guys that we really need to take the time to redesign the software. It's a long-term commitment: the original estimate was a two-year timeframe, and now we've lost one (contract) developer and another was promoted to management.