Software Design is Trial and Error Approach, how true is this statement?

Question

Dear Stackoverflow Readers,

Please comment your votes on how true is following statement:

"Software Design is Trial and Error Approach"

Regards, Rachel

Answer 1

I think if you have bad architecture it is software development is trial and error, but, if you take the time to do a solid design for the features you need first, then there is less trial and error. This is evident in good agile development.

But, if you are doing something new, then there is trial and error, until you have done it enough to understand the intricacies. For example, I am struggling with how to pass an anonymous function to another function that will be put into an object's event handler, so it is a great deal of trial and error.

When I go back to working on writing some data mining functions in Scala or F# that is trial and error because the languages are still relatively new to me.

But, once I have done these for a while, then I expect that there is less trial and error as I will have a library of code to look at for examples, and the understanding of how to approach the problem.

Answer 2

Learning is trial and error, but I most definitely do not agree that software development should be trial in error. Sometimes it is (especially with people who are not as good with software), but there are many methods in place (such as agile methodologies, code reviews, design reviews, unit testing, etc) that should prevent trial-and-error techniques.

Answer 3

I think it's very true. You start with an initial design and then:

1. You implement your design
2. You learn more about your problem and implementation
3. You improve your design
4. GOTO 1

Answer 4

Short answer: It depends.

Longer answer: Software design can be trial and error. If you are not completely sure of the software requirements, and it is something that hasn't been done that way before, it can be trial and error. But where the problem is well defined, and you are using methods that you understand, and where you have developed similar systems before, then it is more like a step-wise refinement. You have a pretty good idea of what has to be done - you build that, and during the testing process made some refinements.

"Trial and Error" implies you aren't really sure if your solution will work, but you will give it a shot, on the understanding that if it doesn't work, you scrap it and try again, hoping that you will lean more about the problem and possible solutions as part of the process. What's the saying - "Nothing is ever a complete failure, it can always serve as a bad example".

While some software design is like that - it shouldn't be. That's what analysis, specifications all of that boring precursor work is for.

Answer 5

Even with a complete spec, there is a "leak" between reality (how the system will work/how people will use it) and the written spec.

The "trial and error" comes from implementing to spec, and then while the software is being usability-tested, adjusting the design to match how people will actually use the software. What seems reasonable on paper is rarely usable as-is. :)

Example:

1. I wrote a management tool, and the spec said the users would drag elements from a list and drop them onto an object. While it worked, it turned out to be much too tedious when there were many elements that needed to be dragged at a time. The thought was to have the ability to select several elements and then drag them over en masse, but upon testing, the easiest solution was to have the user simply click upon the element. A single-click would also remove the element from the object, in the event of mistakes.

2. The spec for a tool required that four lists of data be displayed on a single page, tabbed so that only one list was visible at a time. In reality, the page took a very long time to load, as the data lists were long (500+ elements each). Upon redesign, the decision was made to only load the visible tab on page load and then ajax-load the other tabs when/if those tabs were selected.

In both cases, the spec did not take into account the real-world usability of the system. Was it a design flaw? At the time, no. Going forward, if lists need to be displayed or elements selected, then we will know more and know which (additional) questions we need to ask.

Last example:

• New multi-site system was implemented and performed exactly to spec. Problem was that no one had thought to spec out the maximum time for replication between sites. Now changes to the system take 4 hours to propagate around the ring. :(

Answer 6

Once upon a time, the design of a hammer was surely trial and error. Nowadays, the product is a commodity. Right now, we have multiple corporations designing the same things over and over, I'm sure. Until we all decide to use the same design for some product, we'll keep redesigning it, and relearning the trials and errors that others have already bypassed.

Answer 7

While there isn't always an error, there is something to be said for many things in software being at least a trial, but then this is true of life. We try things out and what works we use and what doesn't, we either change and try again or throw it away, abandon it or whatever one wants to call those paths that are dead ends when it comes to developing various pieces of software.

Yes, this is being somewhat pendatic about the statement in question. Software design often is a Trial and Error Approach but not always is my final answer, Alex.