views:

103

answers:

5

I've often heard that those things cannot be taught, because you can master them only through good gut feeling fed with years of experience. However various patterns and principles are quite well documented and I start to think, that you can actually learn quite a lot of good stuff from books, training and exercises. What is your take? Please discuss.

+1  A: 

There are classes at many schools for software engineering covering design patterns and such things. Yes I do think that it is a good thing to learn for software developers.

Experience trumps all for software development though, no amount of theory and learning can make up for lack of experience.

Overall a good mix is important and best.

Brian R. Bondy
Experience is really important, but some education can save years of trying imho. I don't think design patterns are all, I am looking for a broader approach - maybe going from programming paradigms through formal specifications through some architecture and design patterns and than through general modeling and metamodeling.
Gabriel Ščerbák
@Gabriel, I agree some education can help make the experience more valuable rather than doing, people can be understanding during their experience.
Russell
Unfortunately many of the "patterns" that I have been taught are merely ways to get around language and design limitations. I would much rather that critical thinking and 'silly abstract academic concepts' are taught.
pst
I know some 30 years experience programmer that are making a pure and utter mess and freshmen that are making exquisite code easy to maintain and understand. Experience alone is not enough... education alone is not enough. Neither have precedence over the other, a good programmer will always try and learn new tricks, new methodologies and new ways of doing the same thing. a good mix is not important and best... it is essential.
Newtopian
@Newtopian: All of that is part of experience in my opinion. Agree a good developer will always be learning. People can jog for 30 years, but not everyone is the fastest runner in the world.
Brian R. Bondy
@Brian: Prior to the job I have now I would have agreed with you, it is all what gaining experience is all about. However if your jogger never seek new knowledge and simply get out and run every morning he can end up hurting himself a lot. With programming you hurt others as well as others will have to use and maintain the code, effectively making the whole pack jogging to the lowest common denominator. You would be surprised how low this can be ! I see colleagues everyday still jogging on their knees because they were never taught how to use their feet...
Newtopian
@Newtopian: I'm not in disagreement with you.
Brian R. Bondy
cont: Now it is too late, their minds are closed to learning, they have been doing this for so long, the same way, that the cannot imagine a better way of doing it. Any change for them is a torture. had they been taught from the beginning the basics of structuring the code we would be able to spend more time coding and less time maintaining. But now... 80% of time spent in maintenance is normal. sight... I guess I need vacation !! :-)
Newtopian
@pst you have a point, but the concrete "patterns" aren't as important as understanding of them and OOP in a case of design patterns. If you think of them as language feature fixes, than there should maybe be some ultimate language without any of the known unsupported patterns (let us not talk about SmallTalk here please:)...). I think even with "ultimate" language we will need patterns. Do not forget about others than design patterns.
Gabriel Ščerbák
@Newtopian I was looking into that such of an opinion. Often older developers can teach at slower pace because they do not want to learn something which might be useful only for several months. Young developers on the other hand without guidance will learn, but lack the overall picture and they might be also easily misguided. Structured approach is needed IMHO.
Gabriel Ščerbák
@Newtopian, I will have to steal that jogging on their knees metaphor.
HLGEM
A: 

Design, architecture and modeling are more often than not domains of software engineering/software development as opposed to (pure) computer science.

If you're gearing your students towards software engineering, then this is reasonable, otherwise, it may not be as useful.

Jon Limjap
Hmm, I think modeling as a general approach should be part of computer science.
Gabriel Ščerbák
+2  A: 

A definitive YES.

However how deep you go into the details and techniques depends on the intended use of programming of the audience. Someone basically making quick scripts to help alleviate the repetitiveness of a task does not need as much knowledge as a software architect of a large distributed system.

Both profiles will greatly benefit from learning proper and clean ways to do things. It is all tied together, In my opinion Design and code are part of a whole and must be taught as such.

Q: How do I make sure my program works ?

A: by testing

Q: How do I test ?

A: (teach about unit testing, mocking etc)

Q: Yeah but that is a lot of work, how do I make it easier ?

A: Well you can reduce coupling, isolate better the different parts, reuse code that you have written already...

Too often teachers of programming will stop at the actual language itself, never enter such discussion and that is a shame. Enumerating the tools is not enough to know what to do with them, using the tools is not enough either, you must be also thought proper techniques to use them efficiently.

Newtopian
Thank you. I don't necessarily agree with your questions and answers. Essentially, you have to answer to first question in some serious education "by proof" which is possible, but practically overkill. But you are right that software needs to be designed for testing and when it is not (usually), you have to do the design in your test code.
Gabriel Ščerbák
+1  A: 

I think these are critical things to learn, I've seen far too many applications that clearly have no design but ar ejust a bunch of hacks thrown together. And don't get me started on the serious lack of database design that is crippling most of the COTS (Commercial-Off-The-Shelf) software that it has been my displeasure to support. However, I think we often try to teach them too soon when the understanding isn't there. When I taught, evry database programming books began with database design and none of the students were ready for at that point. You need to understand how to query a database and how to build a basic program and start learning the advanced stuff before the reason why you need to design correctly becomes apparent and then they are ready to learn design. After all design is not that critical to getting "hello World" to work, but try to get the space shuttle software to work without it.

HLGEM
That is what I was getting on by mentioning structured approach. IMHO showing some basic programming in different paradigms might be a good start, what is your opinion?
Gabriel Ščerbák
My technique in teaching database design is to show them how to do some stuff with an existing db, then give them a badly designed one and make them struggle to query it. Then I teach design and we fix the poor design and they see how much easier it is when the design is right. This makes them pay more attention when someone shows them how to avoid those mistakes. So basically I deliberately use the teaching examples to give them more real world type experience rather than all the nice, clean, "everything is perfect" examples most textbooks use. You could do the same in application design.
HLGEM
+1  A: 

Firstly it's not a binary yes/no issue: theory vs experience; I haven't had any 'formal' training at a university; but I have occasionally benefitted from small doses of 'formal' training in small doses: from colleagues, the odd small course, etc. The shport answer is yes they should be taught - but no one should be under the illusion that you only need to do one or they other.

To an extent it depends on who you are - different people learn in different ways; whilst this is often personal there can also be cultural influences (some cultures place relatively more value in academic achievement than others).

For myself, I've learnt on the job, and that includes working with some very experienced peers / mentors. I learn better and faster by actually doing something, making mistakes and correcting my course. The caveat is that you need some mechanism for ensuring your on the right course - for me this was mainly the more experienced people I was working with.

Modeling (for example) is a skill like most others - some people will take to it more naturally that others; and in most cases the more you do it the better you'll become.

An issue I think is relevant to this is the increasing complexity and maturity of the IT architecure related field.

The range and depth of the IT field is ever increasing - there's more to learn, new areas of specialization are emerging. Architecture, design and modeling are IMHO becoming more relevant, and as such they should be "taught" at least to some degree - but like most things formal theory based teaching isn't going to be enough on it's own.

Architecture and Design is benefitting from a popular rise in the use of design patterns, which is making 'formal' design more mainstream (or at least more visible). I think that as disiplines they are much more well understood now than say 10 (?) years ago. On this basis I would say to not teach them would be to omit an important building block in one's knowledge: be it formally or via experience.

Adrian K
I am not asking about how one better grasps new knowledge, but you are still right.Now, please imagine there was an ideal way to teach and learn at university. Would it make sense to teach design, architecture and modeling? I guess your answer was basically yes. I wouldn't say "design patterns" have formalised anything, they only gave names to good designs. Deciding what is a good desing is hard. However different design approaches existed long ago and there was some theory around... I am aiming more at understanding of principles and existing practice.
Gabriel Ščerbák