How can I learn to REALLY design software?!

Question

First off, my focus is web development (ASP.net webforms up to now), using C#. But, I am interested in learning design principles that will carry into any technology or language.

I have been ready for a long time to step up, and learn how to design software the right way. Up to this point, the software I write has been designing the database schema first, using an ORM for data access (usually Linq To SQL), stepping though requirements building a screen (web page) at a time, responding to control events, and when I notice that I am duplicating logic, I will pull that logic out into a utility class or something like that.

I know that this isn't the best way to design software. I think a couple of things have/are holding me back:

• Recently, when earning my BS degree in Computer Information Systems, my teachers focused on teaching the basics of frameworks (.net) and hardly ever touched on design patterns.
• I have never had a mentor. StackOverflow IS my mentor. I am the only developer where I work.

I am currently reading Pro ASP.NET MVC Framework. The 3rd chapter talks a lot about some design patters, test driven development, and domain driven design. I am very interested in these practices and want to start designing my applications first with an object model that reflects the problem domain and THEN letting the rest fall into place.

BUT HOW?! Seriously, I'm not helpless here, but I need to know what to read and study. I am beginning a Masters in Software Engineering program in the fall, but if history is any indicator, I can't rely on a college education to actually teach me anything useful (regardless of how perfect my grades are).

So, to make a long question short, what should I read or study?

Answer 1

Bottom line here is that 'design patters', specifications, development models and all the rest are just systems for getting the job done. don't over think them. Read about them so you know what patterns are accepted conventions for specific problems and why different development methodologies suit different situations.

These things apply to different projects in different amounts. You only learn by knowing what to do and then applying it.

As people have mentioned, the pragmatic books, heads-first design patterns and others are useful.

Just get coding I think, and apply as much as you feel is nessesary.

Answer 2

Reading books is great, but you'll learn quite a bit reading code from large projects. Look at some frameworks which are well respected, even if they aren't in .NET (in fact, maybe even more so)

I'm surprised it's not suggested more: Many swear by agile dogma which opines that programmers in a pair program better than a programmer alone.

Answer 3

In my opinion, architecting and designing software should be a top-down approach not a bottom-up (as you describe). Top-down means you start by designing a set of requirements and specs, as clearly as you can. Based on the specs you build a "framework" and desinging the program following good design principles and patters. Because specs will almost always modify between the starting and ending points, you always have to make your framework modular and extensible. You should create and degine your application layers, build supoprting classes etc... At the very end, you start the actual coding, filling the frameword you built.

Books like : Architecting Applications for the Enterprise or Code Complete 2 are very good books and it's recommended to read them while actively involved in a design process so you can directly apply what you learn.

Answer 4

Get involved in an open source project (or several open source projects): either writing your own from scratch or (preferably) working on an existing one. This will give you exposure to real code, other people's conventions, peer review, and hopefully a userbase of some sort too. There are some excellent books on design principles (another vote for Pragmatic Programmer here, it is excellent) but the experience you get from getting stuck into a real life project is invaluable.

Answer 5

Books are not the complete solution for you, but I have a couple of suggested books anyway...

I found "Software Architecture in Practice" [1] to be very good. Some people would say that design is separate from architecture (but nobody really knows what s/w architecture is anyway). In any case, I deduce from your question that the knowledge you seek is precisely what this book sets out to address.

It can be a little dry in places, and it's full of examples that might seem archaic, but the ideas are still very much applicable.

If you want a list of design patterns, many people swear by Gamma et al [2]. I have found this to be less useful, except as a common "dictionary" to make it easier to discuss a design with other people.

[1] http://www.amazon.com/Software-Architecture-Practice-2nd-Engineering/dp/0321154959

[2] http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612

Answer 6

I would upvote Gortok's answer, but I don't have enough reputation. So instead I'll repeat it.

Head First Design patterns is the book you should read right after taking OOD class in College. Once you've learned how Classes work to encapsulate state along with the methods that operate on that state, and then the magic of inheritance and polymorphism this book provides a great guide for actually implementing these technologies in elegant ways.

Code Complete is a great book about the software life cycle and the things you should be thinking about while coding all the time.

Answer 7

Get involved in a project where you design/code will be critically assessed by others, ask for comments and learn from them.

Answer 8

Here's an essential book on Agile Development. Do not think, just buy. Though the examples in the book are in C#, the principles span any OO language.

Also, any Head First book is essential. +1 to Gortok for the Head First "Design Patterns" recommendation.

Hang in there man. You're going to do great!

Answer 9

Practice, practice, practice.

Don't be afraid to fail.

Continue coding and striving for excellence and you'll be there in 10 years or so. :)

Answer 10

Exposure to a wide variety of methodologies, patterns, architectures, languages, whatever you want to call all that has been beneficial to me in learning how to engineer code. There is no one true language or paradigm or ORM tool, etc. All of them do things differently. All of them bring something to the table and all of them have drawbacks. I, for example, despise SAP and ABAP but I'm thrilled I have work experience with it. It has taught me what not to do for my projects and it's also taught me that some organizations and projects require the very elements I despise. And that's ok. I just know now those projects are not for me. This diversity of exposure helps you develop a sense of style in your software engineering that makse sense to you and can help you help customers most effectively. This is obviously a vague answer but I think it's an important principle to carry with you in your career.

Answer 11

Examine the design and interfaces of frameworks or APIs that you feel are well designed. Look at what parts of the API are strong and what are weak as well as the trade-offs involved. After learning what other developers are doing right and why, those tools will be available to you when you design your next piece of software.

Specifically, I learned a lot about the value of a plug-in architecture from my experience using jQuery.

Also watch videos and talks given by leaders in various fields.

John Resig on API design (1hr)

Ira Glass on good taste (5 min)

Answer 12

In my opinion, the best way to learn how to program well is to work with someone who has a lot of experience. You say you are the only developer where you work. That's not good, especially when you're new to the field.

I think the most important thing you can do is look for another job where there are people that can serve as your mentor. Look for a job in a technology you're unfamiliar with, and state that you have an incredible desire to learn that technology, but never had the chance to use it professionally. It sounds hard, but I got my last two jobs in that exact way. All it takes is a killer cover letter.

Books can only take you so far. You need to get hands on and especially need to get those hands dirty with code. And if you're working with someone that can spot your newbie errors and steer you in the correct direction, you'll be much better off.

Answer 13

Look at solutions, open source software and try to criticize it, make an opinion about the code and try to understand the hard parts. I experienced that this teaches you how to do good design, the best way is to directly look at some code and try to understand it.

The Internet is full of articles, blog posts about best practices. What you should look for is things like

• Design patterns
• Unit testing -> better: Test driven development (hard to do it the right way)
• Software maintainability: handling coupling and dependencies (using metrics), dependency injection patterns, Inversion of control concept
• ...

I try to follow my "personal" list of best practices I'm collecting.

Otherwise there are plenty of good books out there (but just to get the idea, you have to experience it yourself):

• Refactoring: improving the design of existing code
• Patterns of Enterprise Application Architecture
• Implementing Lean Software Development

...just to mention some

Answer 14

One of the books which I didn't see mentioned here was Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides. It is commonly referred to as the Gang of Four book and is required reading in the Software Engineering department at RIT. This book has helped me design software in a way so much better than I have before.

Answer 15

Write programs since practice makes perfect

Then come back to your code a few weeks later and try to add new functionnality. You'll instantly know what you've got wrong in the first place. This is something you'll probably do for some time if you get to a professionnal level, maintain code.

Answer 16

Every time this comes up I suggest that the person enter some design contests at topcoder.com. They give you great feedback on your work and if you do well enough you can win money as well.

Answer 17

What i would recommend, if you're interested in designing software the "right way" (note: there's no such thing), is to get into UML and the Rational Unified Process.

Why? Because it is focused in thinking before doing; you have to think about interaction, flow of events, how does data is stored and why you choose one or another language, framework or database. It may feel like a little "to much theory" but, in the end, when you have to implement your process (your use cases, class diagrams, sequence diagrams, ...) you you'll find yourself programming faster and with more confidence because you want have to guess where to find method X or why should you create Object Y or Z.

It's all about understanding the project before going nuts with code that, if you didn't think about it before, may go to the trash faster than you think.

You think, you prepare the first iteration , you start to code -> second iteration...

It's just a suggestion; i've done this recently and the results where, in fact, much better then my previous projects.