There is an analysis and design phase of the software development life cycle. Should software developers be skilled enough for carrying out the work performed during this phase, such as drawing workflow diagrams, data flow diagrams, ERDs, UML, and other models?
I have seen some cases where developers can code very well given a clear understanding of what is required. However, when they are asked to design a system, they stagger at times.
The design phase is a vital part of the software development process; if you cannot design software, you cannot develop software, and shouldn't be calling yourself "software developer" ("programmer" would be more appropriate).
However, designing software is not about diagrams and flowcharts. It is about figuring out solutions to a given problem on an abstract level, and planning how to translate those into an actual software product. Diagrams and flowcharts help in communicating these solutions and plans, and sometimes they help get a clearer picture, but many software developers have only superficial knowledge of UML, if any, yet they design beautiful software (and, vv., the mere fact that you're an ace at drawing flowcharts says nothing about your ability to design good software). If you can communicate and design well, any tool will be fine; the English language alone will do if nothing else is available.
TL;DR: Yes, software developers should have and maintain design skills, and no, UML e.a. are not requirements for this (though possibly helpful).
The developers should in my opinion always be active in the design. Why? Because they are the ones implementing it. If you have dedicated designers, those designer should also code. It's kind of an eat your own dog shit thing.
It's also not necessarily the best thing to do a large upfront design. Uncle Bob talks a lot about user driven design, and user stories. By breaking the system down into user stories, the developers can more easily see what is needed for the different user scenarios, and this will improve the design, as well as the user experience in most cases. To be able to do this, the developers have to be the designers of the system!
EDIT: Got pointed out that I didn't actually answer the question.
Yes, programmers should be skilled in design, but not necessarily in the traditional large UML diagram sense.
If the team as a whole feels that diagrams are vital, everyone should be able to read it, and enough people should be skilled at making them. I'm not necessarily of the believe that large and complex diagram is what is needed to get the job done though.
Should software developers be skilled at software design?
Yes, definitely. However, design is not necessarily a big monolithic phase, nor does it have to be written down as very formalized diagrams.
The more detailed the design upfront, the more likely it is to prove false later on.
So IMO the skill of designing is not about spitting out a perfect model in abstracto. It's about making pragmatic decisions, starting small and making the design emerge, refining it as you program and discover more about the domain and technical needs.
A good software developer should be familiar with the work that is done at all phases of the software development life cycle, from requirements through maintenance activities, as well as the various supporting activities that happen. That's obviously a lot of topic area to cover, so I wouldn't expect one person to be an expert at all of it.
As far as design goes, I'd expect every software developer to be able to read common models, such as ERD and UML models. This includes the ability to understand what the symbols mean and how the model relates to their role in the process, such as development or testing. I'd also expect them to have enough of a working knowledge to be able to update the models to correspond to their implementation as needed, and the use of the tools used to create and maintain the models.
With respect to actually architecting or designing the system, that's something that comes with time and experience. The only way to actually get good at turning requirements into a system architecture or a high level architecture into a more detailed design is to do it, evaluate your work, and learn from any mistakes. It's not something that can be read in a book or taught in a course or two and mastered.
In my opinion, by and large, any big problem is tackled by breaking it down into smaller problems.
Diagrams, assist in this task. The provide different views/details of the system. At times you are interested in how database schema will look, but other times, you are intersted in how the components will talk to each other. Perhaps, you want to see details of how a particular algorithm will work. Either ways, there is a way to depict a problem/scenario with a diagram rather than text.
Benefit of a diagram is that you don't have to have as much text. Picture bieng a thousand words and all.
For each use case, there is a different level of detail, and different kinds of things need to be thought of.
So in summary, I think it should be a pre-requisite to be able to read those diagrams well, so everyone in the team is on the same footing. The actual task of creating those diagrams, well some are more adept than others, so I would draw the line at reading them. Creating would be a bonus.
UML is a popular notation. One should be familiar with a common subset that is used more frequently. There are details in the standard, that probably only the super experts know about. One should have functional knowledge.
I think that it is good to have all the developers aligned (via education, training or reading) in the various type of UML diagrams and in ERDs and various documents such as requirements (e.g. the Volere template) and details use case listings.
They should be able to read them and use them to describe what they are planning, however, I agree with Thomas that creating architect requires more than that (e.g. experience and systematic vision) and can not be taught.
I am a young software engineer. I am graduating college in a week, but I have been working in the field for the past 2 years. I am currently at a small software company where only 2 of us are developers and our bosses don't do any of the design, or much of it. We sit and talk about it, but none of the true software design is done in these meetings, or well at least.
Being young (and technically an intern), I find it frustrating to be given projects with no specs written, no specifications to look to, just a general final desired result.
I guess my answer is software developers learn software design by having projects designed for them at first, but you should also feel you have a say in how the design happens. The designers might not understand the abilities you have or the shortcomings the developers are working with.
developers can code very well given a clear understanding of what is required.
Even if a user or business analyst can provide specifics on the application requirements, this doesn't tell a programmer how to build it. The ability to design is going to be needed at some level. I agree with the others that the formal use of diagrams isn't a requirement.
A good chef may not be able to write a cook book or perform on a cooking show, but that doesn't mean they ask someone else for the recipes either.
