Should development methods squash a developer's individualism?

Question

I'm in my final semester of college and am taking a software engineering course. In the class we learn about various software development methods. The one we focused on, and used to develop our project, was the waterfall method.

I feel like the instructor may have implemented it wrong. In our class diagrams, we had to list ALL properties and methods including private ones. I have read a few books, namely Clean Code, that say to keep functions as short and focused as possible. It seems tedious to list every little function in our diagrams if they don't help other developers out (they're private, no one else will use them). Plus, I may not think of every tiny function when designing the program, they may come along when refactoring.

Did the instructor tell us wrong by asking us to list every function? And, do these design methods squash the developer's individualism to write code how they can best understand it?

Answer 1

Did you ask the instructor why you had to list all the methods?

It is possible that, like with much of what is asked for in a classroom environment, the intention was not to make your class diagrams more helpful to developers but to help you and your classmates think about how you would design your classes. When students are learning how to decompose larger problems into smaller problems, it's probably helpful for them to think about what private methods they would likely need. And it's probably helpful for the instructor to get a better idea of what methods students are thinking of implementing in order to intervene earlier in the process if someone's design is poorly thought out. Documentation in a classroom environment is often much more involved than documentation in a real world environment because the instructor's intention is that writing the documentation forces students to consider things that they might be too inexperienced to think about if they are just focused on their code.

Of course, it is also possible that the instructor believes that this level of documentation is helpful in a real project. If that's the case, the instructor is probably either out of date or came from a particular niche background where this level of planning and documentation is appropriate. If you're building the navigation system for the space shuttle or designing medical devices, for example, it's generally far more appropriate to invest heavily in design up front rather than refactoring code during development. If you're developing a social networking site, on the other hand, a more agile approach is more appropriate.

Answer 2

No, the instructor is right in telling you to list all the properties and methods upfront if you are using the waterfall method. Wikipedia notes a criticism of waterfall:

Many argue the waterfall model is a bad idea in practice—believing it impossible for any non-trivial project to finish a phase of a software product's lifecycle perfectly before moving to the next phases and learning from them. For example, clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it. They may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the project's resources has already been invested in Big Design Up Front.

These design methods don't squash the implementer of the design's individualism as there are still parts to interpret and ways to put one's unique touches on the structure,e.g. picture given a skeleton and adding the muscle and other tissues to create an animal wondering how much freedom did you have to design that animal?

You have found a shortcoming of waterfall yes but everything has its strengths and weaknesses.

Answer 3

In the class we learn about various software development methods. The one we focused on, and used to develop our project, was the waterfall method.

You probably learned the classical Waterfall model, which the person attributed with introducing it to the software development world stated from the start was inappropriate for developing large-scale software systems. You would probably be interested in reading Winston Royce's paper titled Managing the Developemt of Large Software Systems to learn more about the problems with what many people consider to be the Waterfall model.

However, the Waterfall model is good for teaching the software development lifecycle as you go through and can spend time learning about and performing requirements engineering, architectural design, detailed design, implementation, testing, and maintance in very clear, distinct phases.

In our class diagrams, we had to list ALL properties and methods including private ones. I have read a few books, namely Clean Code, that say to keep functions as short and focused as possible. It seems tedious to list every little function in our diagrams if they don't help other developers out (they're private, no one else will use them). Plus, I may not think of every tiny function when designing the program, they may come along when refactoring.

These are all very valid points.

Listing all properties and methods during the design phase, even when using Waterfall, is probably overkill. You should definitely list everything that's public, along with the essential properties. In reality, everything else is an implementation detail that you can obtain by reverse engineering your implementation into diagrams.

Clean Code's advice (I've never read it - I'm just going by what you posted) seems to be fair, and applicable even when using the Waterfall methodology. You can design your classes and methods with respect to the Single Responsibility Principle, separation of concerns, and other principles of SOLID. Waterfall doesn't tell you how to design, just when you need to do it. That said, it is harder up-front as you learn and think of better ways to do it during implementation.

I think this points out the fact that there needs to be iteration between design and implementaion very clearly - a problem that traditional Waterfall doesn't account for.

Answer 4

It seems tedious to list every little function in our diagrams if they don't help other developers out (they're private, no one else will use them).

If you think this is tedious, wait till you get a real job programming. Consider, for a moment, that software may not be a viable career for you.

Plus, I may not think of every tiny function when designing the program, they may come along when refactoring.

So?

did the instructor tell us wrong by asking us to list every function?

No. It's a common requirement.

And, do these design methods squash the implementer of the design (the developer's) individualism to write code how they can best understand it?

Yes. The soul-crushing of individuals is an important part of software development. All individuality will be beaten out of all programmers at all times in all possible ways. It says that somewhere in the "God's Rules of Programming" handed down from some mountain to some prophet.

No. You're just balking at the tedium. Get over it and get back to work.

Answer 5

Programming is the art of working within constraints. The CPU provides a limited instruction set; IO is constrained by the design of the hardware; OS APIs are created to encourage certain behaviors and restrict others; high level languages are often designed to promote one set of idioms over others...

And methodologies too are crafted to restrict.

Your challenge, in all aspects of the development process, is to realize your vision within those constraints. Will you bash your head against each wall thrown up by hardware, language, API, and methodology? Or will you find a way to harmonize what you wish to achieve with what is allowed and encouraged?

Do you really think your instructor wishes to read through endless pages of minutia? Then test that theory: break a program up, and document each atom. When his desk is sagging under the weight, I rather suspect you will find that his true desire is somewhat different from what you expect.

Or prepare the documentation as you see fit. Make it clear, make it understandable, make it read like a Dashiell Hammett novel. And then sit down and talk to him, show him what you've done, convince him of its merit.

Answer 6

A simple rule of thumb to gauge project analysis complexity is "Can the developper or the company he works for can be held responsible for something dramatic enough (generally including death or huge amount of money lost) happening with the software created?".

I had the same experience as you for some of my courses. People who had a background in the miltary industry would teach us analysis. And that would be complete and exhaustive analysis, planning all the course of the project, even in the smallest details. You cannot afford much iterations with this kind of project (also bomb exploding can be ok, budget exploding are not), so no place for creativity here, you have to go by the plan.

On the other hand, if you have read a bit, you certainly read about agile methodologies. There is generally less documentation, and more room for the developper to use his creativity while developping a solution to the problem he does encounter.

In conclusion, the more experience you get, the better, and what your instructor is showing you does apply in some part of the industry. Just be aware that there are certainly as many way to manage and design a project as there are to code them. And you will find defenders and critics for all of them. Test them while you are studying, and choose the one you're happy with.

Answer 7

I think the instructor is brilliant for making you do this project, and thus teaching you the pros and (mostly) cons of Waterfall development.

Answer 8

I think your instructor is out of touch. Commercial software is rarely designed or documented to that extent. It's far too expensive, and the resulting documentation cannot be maintained without even more expense. IMO such practices are a legacy from days when coding was often done in assembly language. Your time would have been better spent trying more agile practices: test-driven development, pair programming, continuous refactoring.

Did the instructor "tell you wrong" ?

I think so.

Assigning boring work to intellectual property workers is wasteful. In school, boring work has little or no pedagogical value, except perhaps to inure students to boring work. Such exercises have negative consequences, both to the students, and to the industry. The students are harmed because their time is wasted. The industry is harmed, because some students may conclude that such tedium is necessary, and useful. It is neither. In thirty years in software, the only work I can think of that was both boring and useful was changing backup tapes. There were robots that could do that, but they were prohibitively expensive.

Answer 9

Some software engineering classes, such as the one I had, are taught in a weird style where 'failure is success', success is a wasted opportunity to learn from failure, and more is less and less is more. If this is one of those, then just stick with the assignments and enjoy the weirdness.