A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
There have been a lot of DoS postings on the JoS board, with several that comment on how there isn't enough traffic on the DoS forum. I think that Dave Jarvis's post below proves that theory wrong!
I suspect it appears that there is less traffic here because (generally) the technical questions require fewer answers than a post asking peoples opinions. I think there's also a tendency to not answer homework type questions at all.
In any case, I thought that the DoS board might be dying, but perhaps there's still hope.
I suspect that the discrepancy is a form of the bike shed problem:
[ http://en.wikipedia.org/wiki/Color_of_the_bikeshed ].
Everyone has an opinion on something of a general form - what color do we paint a bike shed, for example - but there are comparatively fewer people who can offer a meaningful opinion on a specific technical question. This is exacerbated on the web, as it is relatively difficult to provide sufficient context for an outside audience to approach your problem meaningfully. I don't think DoS should die by any stretch, but I think it deserves mentioning that a post asking for advice on application design is going to get fewer substantive replies than a post on compensation / benefits.
There are about the same number of useful posts - if you discount all the posts on JoS about how:
1, Open source / offshoring / H1B are taking all our jobs.
2, Anyone without a CS degree is a stupid amateur but anyone with a PhD is a head in the clouds academic.
3, Desktop apps are always better than web apps.
I think that designing should not go too much into technical issues. Of course someone has to design and implement the technical widgets and platforms that are used all over the software, too.
When I _define_ some software, I write down what the software does, what it stores, what it produces, and that kind of general stuff.
When I _design_ the software, I want to concentrate on the designing of the data flows, state systems, entity diagrams, and so on. This is not so much technical than definitional approach.
It is an unnecessary burden for the software designers to talk about technical details. The technical details should be left to some other person, maybe to the software architect.
Then a software architect defines and designs all widgets and platform issue concerns. It is the responsibility of the architect that the designed entity diagrams and state charts can be realized in the software with ease by the programmers.
Finally in the end, the programmers program everything. Or the programmers could use some tools to just plainly import the designed charts and diagrams into the software being developed. This is the right way.
Surely we can discuss what are the exact roles and titles for the people involved in software development, but the main idea is that the process should be improved. For example there could be separate design architects and technical architects. The design architects are the heads of the designers and the technical architects go for the widget and platform issues.
A programmer can work with the rest of the people for common goal and suggest approaches for the heads, but the programmers should not be responsible nor have to worry about the higher level stuff.
Wednesday, April 16, 2008
I think it boils down to a question of how much deep thinking is required. The more useless a topic the less thinking you have to do so the more opinions and questions you will get. Since design of software requires a lot of thought you get less opinions and questions. I have ditched all the other ofsoftware forums and read only design of software forum now (mainly because I dont have much time to spend on forums). From bottom to top, I have read almost the entire archive.
Friday, April 18, 2008
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz