How to improve software design skills?

Question

In my point of view, design ability is harder to get than development/coding skills.

When confronting a requirement , how to design the function modules, how to construct the program architecture properly?

By the way, are there some books related?

Answer 1

Trial and error is the best way to see how your own designs can improve. Always look for a better solution. What mistakes did you make? What part was less flexible than it needed to be? What caused you to have to hack around a design decision you made?

Think about the implications of the design rather than purely it's flexibility and elegance. What trade offs have you made in order to make this reusable? Are you following the seperation of concerns and the single responsibility principle? Open closed principle? Do you know what these are and their implications?

Also study the work of experts in the form of design patterns.

Read Design Patterns Explained by Shalloway, Read Head first design patterns

However remember that these aren't magic bullet solutions and take everything with a pinch of salt. Use your own creativity and STAY PRAGMATIC.

Answer 2

I think it all comes down to experience. Being able to read a set of requirements and translate them into a good, clean, maintainable software design is one of the hardest thing in programming (imho) and you do not learn that just by reading a book. It's about trying, making mistakes, learning from those mistakes, and learning what designs have worked for you in the past or haven't.

For me, it often helps to really take my time and create a good design in UML, for example a class diagram. It often helps me identify and components that I can reuse throughout the software application, where I can use a certain design pattern, etcetera.

A few books I can recommend: Software Architecture in Practice, which is a very good book about software architecture, and Design Patterns by the Gang of Four, which is a great reference for any design patterns you might use.

Answer 3

I don't believe there is any substitute for experience and talent, and I've never read a book on software design that I could recommend from the point of view of teaching design, despite having read quite a few. Some people are good at it, and get better as they gain experience, and some are not, and never seem to learn. Sad, but true.

Answer 4

I think the answer is what most mediocre programmers often don't do: read other people's code and learn from it, analyze its strengths and weaknesses, and also incorporate in your own programming tricks bag what you see interesting. There are many good techniques that are already invented, will empower your coding skills and save you lots of time.

There are many high quality code out there in open source projects to research.

Answer 5

I think by looking the design of some great open source projects available .Reading the Code and looking the design of opensource projects is the best way of learning designing in my opinion.

Answer 6

Instead of saying "trial and error", let's say "iteration".

Whatever you're designing, just give it your best shot with the information you have, knowing you don't have complete knowledge. Then you will undoubtedly run into an unforeseen issue that complicates things. This is when you have to ask yourself what went wrong and what to do differently. Then go back and redesign/reimplement with your new understanding. Repeat. Always be second guessing your design and be looking around you for better solutions. For example, "How does Firefox implement find? Oh, I see, they don't use a popup window, and its much cleaner."

By accepting the fact that you will make mistakes and are willing to fix them, you're already way ahead of the pack.

As you gain experience, you're iterations will become longer, and once in a while you'll get things right the first time -- no doubt because you can foresee mistakes and their solution from the past.

As far as books are concerned, if I remember correctly, "Inside Steve's Brain" talked about how iteration is intrinsic to Apple's development.

Answer 7

I agree with most suggestions so far, they are all valid - read code, read books, try stuff.

Where I have seen the biggest gains, both personally and in team members is a two-fold attack: 1. Get them out of their comfort zone - i.e. an unfamiliar domain or language, take away the crutches. 2. And, probably more importantly, pair them with someone who is already experienced.

Mentoring has a lot to offer, you can get there yourself, but a good mentor can save you years of pain.

Answer 8

Certainly, experience is the right answer. But beyond that, I think there's something to be said for understanding patterns in your own context: As you're building your applications, make design decisions that make pragmatic sense to you. To wit, don't do them because it's 'best practice', or because a more experienced programmer told you to. Do them because you understand the Why and it helps you (or other programmers) work with the code and understand it better. I find the same is true with things like database design. Do what makes sense from an intuitive, maintenance standpoint. 7 times out of 8, if you've really thought it through (or learned from various pitfalls), you'll find you're automatically doing some class of 'pattern' or practice without actively trying to.

Of course, I'm not suggesting anyone work in a vacuum; nor that they don't actively pursue and integrate design patterns as a matter of course. I just think that understanding them in your own context (and for specific, practical reasons) is what helps the most to demystify the thing. That's been my experience, anyway. Reading books always feels like learning-lite to me. Good helpful stuff, but small potatoes next to getting in the slop. Think your decisions through and be able to defend them. Always be open to a better way.