Software planning
-
I think there is this management attitude out there that if software is carefully planned, with careful design and nice UML diagrams, the latest software theories rigidly adhered to the result will be a first rate software program. As I see it there are two problems with this approach 1) No one can predict the future - there are always unexpected problems and new feature needed that pop up that no one could have predicted which will mess it up. 2) Management types don't know what they want until they see it. They constantly change specs. If they won't commit themselves how can development team further down the pipe commit themselves? While I think some planning is good it should be a secondary concern and not a primary one. The primary should be creating a good product.
A cynic is a man who, when he smells flowers, looks around for a coffin.
-H.L. Mencken -
I think there is this management attitude out there that if software is carefully planned, with careful design and nice UML diagrams, the latest software theories rigidly adhered to the result will be a first rate software program. As I see it there are two problems with this approach 1) No one can predict the future - there are always unexpected problems and new feature needed that pop up that no one could have predicted which will mess it up. 2) Management types don't know what they want until they see it. They constantly change specs. If they won't commit themselves how can development team further down the pipe commit themselves? While I think some planning is good it should be a secondary concern and not a primary one. The primary should be creating a good product.
A cynic is a man who, when he smells flowers, looks around for a coffin.
-H.L. MenckenJWood wrote:
While I think some planning is good it should be a secondary concern and not a primary one. The primary should be creating a good product.
Agreed, but planning is different than designing. If you design the software and its architecture, automatically you figure out how much time (at least approximately) you need to implement each component. And adding features is easier. So the "planning" of the software development (or lifecycle) is simpler to accomplish and generally more accurate.
________________________________________________ Tozzi is right: Gaia is getting rid of us. Personal Blog [ITA] - Tech Blog [ENG] Developing ScrewTurn Wiki 1.0 RC, now with AJAX Preview.
-
I think there is this management attitude out there that if software is carefully planned, with careful design and nice UML diagrams, the latest software theories rigidly adhered to the result will be a first rate software program. As I see it there are two problems with this approach 1) No one can predict the future - there are always unexpected problems and new feature needed that pop up that no one could have predicted which will mess it up. 2) Management types don't know what they want until they see it. They constantly change specs. If they won't commit themselves how can development team further down the pipe commit themselves? While I think some planning is good it should be a secondary concern and not a primary one. The primary should be creating a good product.
A cynic is a man who, when he smells flowers, looks around for a coffin.
-H.L. MenckenJWood wrote:
if software is carefully planned, with careful design and nice UML diagrams, the latest software theories rigidly adhered to the result will be a first rate software program.
Most likely, you will hear: Managers say that if the software is carefully designed, ... Designers say that if the project is carefully managed, ...
Best, Jun
-
I think there is this management attitude out there that if software is carefully planned, with careful design and nice UML diagrams, the latest software theories rigidly adhered to the result will be a first rate software program. As I see it there are two problems with this approach 1) No one can predict the future - there are always unexpected problems and new feature needed that pop up that no one could have predicted which will mess it up. 2) Management types don't know what they want until they see it. They constantly change specs. If they won't commit themselves how can development team further down the pipe commit themselves? While I think some planning is good it should be a secondary concern and not a primary one. The primary should be creating a good product.
A cynic is a man who, when he smells flowers, looks around for a coffin.
-H.L. MenckenJWood wrote:
The primary should be creating a good product.
By good product, do you mean from the user's perspective, from the developer's prospective, from the QA's prospective, etc? Something you learn in TQM is that a product has many customers, each with different qualifications of what "good" means. I don't think it's possible to make a good product that is holistically good without proper design. And bad design tends to percolate to the top where it's reflected in QA testing, acceptance testing, usability, and maintainability. All of which affect the bottom line that the manager should be interested in. However, anyone can draw a Mickey Mouse UML diagram. It may be management's attitude that careful planning and careful design will make a first rate software program, and I would agree, because "careful" implies, to me at least, that there are competent and skilled people doing the design. And a careful design will be able to accomodate a considerable amount of unforseen changes, because a skilled designer will consider that in the design because he/she is being careful. So, the manager has every right to expect flexibility in the design and a first rate software program. While it's easy to have an adverserial relationships with management, one can also have a synergistic relationship, if the manager understands that he/she is also part of the design process! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
JWood wrote:
The primary should be creating a good product.
By good product, do you mean from the user's perspective, from the developer's prospective, from the QA's prospective, etc? Something you learn in TQM is that a product has many customers, each with different qualifications of what "good" means. I don't think it's possible to make a good product that is holistically good without proper design. And bad design tends to percolate to the top where it's reflected in QA testing, acceptance testing, usability, and maintainability. All of which affect the bottom line that the manager should be interested in. However, anyone can draw a Mickey Mouse UML diagram. It may be management's attitude that careful planning and careful design will make a first rate software program, and I would agree, because "careful" implies, to me at least, that there are competent and skilled people doing the design. And a careful design will be able to accomodate a considerable amount of unforseen changes, because a skilled designer will consider that in the design because he/she is being careful. So, the manager has every right to expect flexibility in the design and a first rate software program. While it's easy to have an adverserial relationships with management, one can also have a synergistic relationship, if the manager understands that he/she is also part of the design process! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithWell put. 5.
:josh: My WPF Blog[^]
-
I think there is this management attitude out there that if software is carefully planned, with careful design and nice UML diagrams, the latest software theories rigidly adhered to the result will be a first rate software program. As I see it there are two problems with this approach 1) No one can predict the future - there are always unexpected problems and new feature needed that pop up that no one could have predicted which will mess it up. 2) Management types don't know what they want until they see it. They constantly change specs. If they won't commit themselves how can development team further down the pipe commit themselves? While I think some planning is good it should be a secondary concern and not a primary one. The primary should be creating a good product.
A cynic is a man who, when he smells flowers, looks around for a coffin.
-H.L. MenckenJWood wrote:
- No one can predict the future - there are always unexpected problems and new feature needed that pop up that no one could have predicted which will mess it up.
An experienced developer always creates a flexible plan and design that will allow for most problems and changes that come along. Whilst we can't predicate exactly what will happen, experience teaches what will probably happen.
JWood wrote:
- Management types don't know what they want until they see it. They constantly change specs. If they won't commit themselves how can development team further down the pipe commit themselves?
A good plan will help avoid these kind of issues. The more up front planning you do, the earlier that management and yourself can spot the flaws.
JWood wrote:
While I think some planning is good it should be a secondary concern and not a primary one. The primary should be creating a good product.
I'm very much of the old school. If I don't have a detailed plan then I don't feel happy or comfortable with a project. My current employer hasn't been much for pre-planning and take a very haphazard approach to building software. So I face the opposite struggle of trying to explain why a good upfront plan and design, save lots of heartache further down the round.
Michael CP Blog [^] Development Blog [^]
-
JWood wrote:
The primary should be creating a good product.
By good product, do you mean from the user's perspective, from the developer's prospective, from the QA's prospective, etc? Something you learn in TQM is that a product has many customers, each with different qualifications of what "good" means. I don't think it's possible to make a good product that is holistically good without proper design. And bad design tends to percolate to the top where it's reflected in QA testing, acceptance testing, usability, and maintainability. All of which affect the bottom line that the manager should be interested in. However, anyone can draw a Mickey Mouse UML diagram. It may be management's attitude that careful planning and careful design will make a first rate software program, and I would agree, because "careful" implies, to me at least, that there are competent and skilled people doing the design. And a careful design will be able to accomodate a considerable amount of unforseen changes, because a skilled designer will consider that in the design because he/she is being careful. So, the manager has every right to expect flexibility in the design and a first rate software program. While it's easy to have an adverserial relationships with management, one can also have a synergistic relationship, if the manager understands that he/she is also part of the design process! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithRequirements analysis if done proper is the bedrock. Unfortunately, there are many documented cases where requirements analysis was not conducted in a proper manner causing quality assurance problems. Alas, another key failure of software design is where requirements change with alarming regularity largely due to somewhat incompetant upper Management who are not steering their organisation with consistency thus goalposts constantly change. Thus quality often takes a hammering, prices become higher perhaps to the point where cancellation can occur, and project timings become haphazard again causing probable concellation. An example of poor management of the requirements analysis is the AMR scope creep software disaster [^] For a good quality management guide have a look at [^]
-
I think there is this management attitude out there that if software is carefully planned, with careful design and nice UML diagrams, the latest software theories rigidly adhered to the result will be a first rate software program. As I see it there are two problems with this approach 1) No one can predict the future - there are always unexpected problems and new feature needed that pop up that no one could have predicted which will mess it up. 2) Management types don't know what they want until they see it. They constantly change specs. If they won't commit themselves how can development team further down the pipe commit themselves? While I think some planning is good it should be a secondary concern and not a primary one. The primary should be creating a good product.
A cynic is a man who, when he smells flowers, looks around for a coffin.
-H.L. MenckenI think you're talking about the "comprehension gap" that often exists between management/commercial/customers and the development team. I haven't worked anywhere that doesn't have this situation. As a developer I used to become frustrated by the constant rework generated from a meeting with the commercial group but now I realise that its important for two reasons. 1. The more reworks requested by commercial the closer we, as a development team (yes that includes management/commercial/customers and the developers) get to a product that they are happy with. 2. If they (commercial) are happy with the product, the greater chance they can sell it to customers and pay mthe developer their salaries! It may sounds like I'm high as kite, secretly a sales manager or making this up as I go along but using this theory gets me through the day. Expect change... think Agile.... Cynic is what a pessimist calls a realist!!!
-
I think there is this management attitude out there that if software is carefully planned, with careful design and nice UML diagrams, the latest software theories rigidly adhered to the result will be a first rate software program. As I see it there are two problems with this approach 1) No one can predict the future - there are always unexpected problems and new feature needed that pop up that no one could have predicted which will mess it up. 2) Management types don't know what they want until they see it. They constantly change specs. If they won't commit themselves how can development team further down the pipe commit themselves? While I think some planning is good it should be a secondary concern and not a primary one. The primary should be creating a good product.
A cynic is a man who, when he smells flowers, looks around for a coffin.
-H.L. MenckenTo add to what others have posted, I beleive and important factor is the view and scope. By that I mean, it is great to have an overall design, but when you get down to the details I think things work better using iterative methods. As you mention, it is common that you get feature creep and a project can remain in a state of development forever. If a person breaks down the large scope and focuses on the most important areas first with iterative practices of development/review cycles, the project is more apt to have a completion and with less gray hair.. In the past, I have known people that detail out an entire large scale application and more or less build they entire app before serious debugging or even allowing review. Way too often I heard the old phrase "you got just what you asked for, but not what you wanted" along with seldom every having a stable product. I believe more in an iterative development cycle breaking things down and building them out to the desired usefulness. This has always saved me a great deal of time and while I experience some feature creep, it is handled before it affects others areas of development to reduce recoding. Often I end up with a solution that is very different from the original specs but very close to what they really wanted.
Rocky <>< Latest Code Blog Post: ASP.NET HttpException - Cannot use leading "..".. Latest Tech Blog Post: Anti-Spam idea - Help!