Software Design Is it worth it? 1

[richfield]

Hi,

A few colleagues of mine have been discussing the issue of
the whole idea of design, as a process or product during software development.

I was wondering on all your views on the contention that, Choosing the best notations, tools and working methods is more important to successful software design than the developer's experience of the selected programming language, paradigm and supporting libraries.

It would be interesting to hear different viewpoints based on your experiences.

Look forward to reading some of your thoughts.

Rich

 

[EdwardJS024]

In some parts of the carribbean islands where there are abundance of lakes, streams and rivers. Many local natives devised a way to fish using bamboo, nylon and a hook.


Give an experienced engineer a notepad and a compiler, and the output will be of greater quality than a junior developer with the most spohisticated tools. (not measuring velocity)

 

[stevexff]

There's more to programming than just knowing the language. Knowledge and experience of algorithms and patterns probably count more than how well you know the syntax of the language. Take .NET for example. Anyone who knows C, C++, or Java can probably learn the fundamentals of coding in C# in a week or two, it's just a case of mapping what they already know onto the new language constructs. But if you don't know the .NET framework, then you've got a much bigger task on your hands. Ask a VB6 programmer with a limited grasp of object oriented principles to start coding in VB.NET, and see what happens...

 

[ACAMBAROGTO]

Appropiate planning is always the basis of best results, but under the same circumstances, a more experienced programmer who knows the ins and outs of a language or languages would deliver better results. I don't think one is a substitute to the other.

 

[grooke]

YOu need planning. Not too much but just enough.

Your question sort of reflects this, because you use the word 'paradigm'. What is that? Surely it is just a knowledge of some architectural pattern. Without it you get chaos and seldom a finished project.

On the other hand, you need some common working ground, which implies 'agreed working methods'.

My experience says that too much planning almost guarantees a failed and irrecoverable project.
My experience also says the same about too much methodology.

You need common sense. Agile development tries to get this.
Dont do anything until you are sure that it is worth doing.
Have the team build up their own joint detailed pethods by working as pairs.

Dont write the whole spec, but get the highest priority sketched out with sufficient detail that the developers and testers can work out what is required.
Then deliver that part of the system to the users in working condition, and let them say what changes they want.
Only document enough for your readers to probably be able to work; never document' what you know'.
Only plan and design enough so that the succeeding workers can co-ordinate their efforts; dont lay out every detail.
Only work on what you know you can do in a week or two; dont try and start the lot.

This approach minimises the planning and maximises the flexibility from the user's point of view because they can always change their minds. The minimising saves more money than the refactoring produces.

By having the team work as constantly changing pairs, not only do you save considerable detail in the documentation, but the team methodology builds itself around the skills of that team, NOT some mythical team that we must all emulate. Of course, some tools like UML and a simple agreed minimum are nedded, but if the team decide that simple SSADM is better for them, despite being and old technology, then that should be acceptable.

I believe that there is a strong future in agile analysis, where the user and the BA form the first pairing and the programmer and the user possibly form the last. Encourage flexibility.

Gil

 

[EdwardAtSGI]

Choosing the best tools is only useful if your developers can use those tools. Using the best tools does yield a great result in the hands of good developers, so I wouldn't write it off entirely.

As for general planning, well we all sure hope someone's doing it. Heh.