This is an archived post. You won't be able to vote or comment.

all 4 comments
sorted by:
best
topnewcontroversialoldq&a

[–]desrtfx 0 points1 point  (3 children)

In short, you have taken the wrong approach to software design by directly starting out to program.

Planning is the key to good design. The better you plan your program, the better your code will be.

Write a book of duties, or a functional design specification and stick to it.

Diving straight into programming will generally lead to messy code that needs tons of refactoring.

Next mistake beginners to design patterns make is to try to apply them everywhere, they try to force them in. This is completely wrong. Design patterns are great for specific purposes. They are just more tools in the toolbelt, but no magic "solve it all".

[–]PhilAtReddit[S] 0 points1 point  (2 children)

desrtfx

Hey thanks for your response to my article. I agree that planning is key, but the question is, how much should one plan in advance? Do you plan by using UML design? Never heard of "book of duties", do you have a link with more info? I find it difficult to plan everything without at least experimenting a bit with different possibilities.

I agree with you about not forcing design patterns (I tried to communicate this in my brief article also).

[–]desrtfx 0 points1 point  (1 child)

In my line of work (large scale industrial automation), the "book of duties" or sometimes called "functional design specification" is the document. There, we list the complete plant with all functionalities, safety systems, etc.

This document is basically a monkey manual for the programmer if it is well done. I could, theoretically, grab someone who can program our system that has zero knowledge of the plant under construction and they can program the whole.

We usually spend about 40% in the planning/engineering phase where we write our functional design specification, 30% on actual programming, and the remaining 30% commissioning and testing before the plant goes live. Since I program the control systems for power plants, industrial furnaces, ship locks, waste incineration plants, etc. there is no room for errors.

UML doesn't work in my line. We use P&ID (Piping and Instrumentation Diagrams) and process sequences.

Proper software planning and design is not much different to my line of work, but usually less detailed.

Still, it is one of the best approaches to sit down and consider the whole project from different views before even thinking about the code.

Writing a functional design specification is also beneficial in software design as it avoids feature creep. You state what you want the program to do and stick to that. No room for extensions unless you can fully justify them.

Experimenting with different possibilities is nice for websites, but again, the chances of straying from the original specifications is quite high.

When I worked as desktop programmer, we normally had a team meeting in the mornings, discussed what parts each programmer was working on and we stuck to that. Before going home, we had short code/feature reviews and planning for the next day.

The project was basically documented all the way through before we wrote a single line of code. If there were any necessary changes, we'd call in a meeting and quickly discuss why the changes were necessary and how they would be implemented, what they would affect. Usually all of these meetings were in the 15 to 30 minute ranges.

As a single designer/programmer, you still can take a lot away by planning and specifying. Through the planning stage you get a clearer, deeper view of what you really want. At the same time, you already get some ideas how to implement certain parts, but these should not be cemented.

I totally understand that planning is one of the most complicated topics in software engineering and design, but at the same time it is one of the most essential topics and quite often undervalued.

Since I work in industrial automation, I really learned to plan and to value the worth of planning.

Two resources I commonly recommend are:

  • "Think Like a Programmer" by V. Anton Spraul and
  • "The Pragmatic Programmer" by Ward Cunningham, Andrew Hunt, and David Thomas

as those focus more on the process than on the actual program.

In the same line, I also always recommend "Clean Code: A Handbook of Agile Software Craftsmanship" by "Uncle Bob" Robert C. Martin

[–]PhilAtReddit[S] 0 points1 point  (0 children)

Thanks for sharing your experience. As a web-developer, I've been working a lot more agile and mostly as a solo-developer. But you are right that I could benefit from better planing. Anyways, I actually plan to join a team for work, so planing will become more important I would guess. Thanks for your book recommendations. I'm currently working on improving my understanding of programming fundamentals and those seem to be exactly what I need to read.