3 ms·

Lack of design in software nowadays was cited as a problem in the post. I agree, and I think there's a lot of not-classically educated hands out there that wou

Lack of design in software nowadays was cited as a problem in the post. I agree, and I think there's a lot of not-classically educated hands out there that wouldn't know a good design document from bad. Nor would they have any practical knowledge of a combination of: how to structure code in large code bases, test their code, converse about/apply software patterns, document their API's for public consumption, RAII, SOLID, TDD, etc. So, I think there's little hope for improvement in software quality/design/success metrics/etc. Big up-front design only satisfies document weight tests and typically does not stay up to date with the software. So, just simply saying "we need more design" is not going to get us anywhere but hell. Self-documenting code is a nice idea, but scales only so much in a large codebase. UML is a bear to produce and maintain, and I only really like it in whiteboard discussions, not actually drawn in a tool. Wikis devolve into a mess of disconnected ideas. Successful teams I've been on tend to rally and organize designs around the already generated documentation (like JSDoc or JavaDoc), but those docs often only focus on the user-facing API's and leave the internals as a partially documented wasteland. A few teams I've been on had a scribe, which was sweet, but not usually. What patterns of design and documentation actually work well for you in real-world, large project/team scenarios? Regarding needing an aged "adult in the room" to guide the fledgling developers to glory, as I think the OP suggests is an answer to the problems ... Well, in my many experiences where imparting wisdom from on-high was the goal, that has been a miserable failure. It was all because said "senior architect" or whatever the title was invariably only cared about blessing random big decisions randomly/destructively and had otherwise checked out to walk his dog after lunch and otherwise coast during his pre-retirement. All I can say is, God bless 'em. I do NOT count on age as a factor, only that a developer has reached a certain point of experience in their career. What I DO count on is one person who can enforce a clear vision with passion. Who holds the torch for your team? Is their grip shaky or firm? Where are we headed? Are we headed there with conviction? Does the end goal still seem plausible to all hands after every step we take? If you have proven you've got the chops and can back up all your assertions with creditable past successes and/or literature, you can rule your team and demand excellence - YOUR excellence! Pick a darn direction and let's go! I have total respect for that someone that has a coherent vision AND can communicate it. Agile methodologies sound plausible to address design and software productivity issues, but I have yet to see exceptional results from an agile project vs waterfall. This is probably just because software is a hard thing to do well in any case, and is subject to political winds, funding, ineffective product owner, etc.

jakejake 12y ago
I have to agree that age alone doesn't necessarily mean anything. I know plenty of lazy, mediocre old programmers. But in order to run a project it does help to have gone through many project launches using different methodologies. That usually takes a few years of professional development, seeing fads come and go, learning to work with different personalities and, honestly, even screwing up a few times.
einhverfr 12y ago
I would agree but I would also say that good design takes a lot of time and practice to get right. You don't want to design too much up front, but you don't want to design too little. The top-level design really shouldn't be that detailed. The component design should get progressively more detailed. One of the best things programmers can do is to learn software design and I don't mean UX design but rather API design. Be conscious of what you expose to the world. Be conscious of your interfaces. Design your interfaces. Think through error conditions etc. This allows you to push a lot of component design down to the people actually doing the work. I have been instrumental in pushing my largest client at the moment from a fast programming mentality to a contract-oriented design mentality. The goal is to speed up the development of those components that need to be developed in a more agile manner by providing greater stability in a platform they can rest upon. You can't program fast if the ground changes under your feet (or rather you can but you will never get anywhere).

jakejake 12y ago

I have to agree that age alone doesn't necessarily mean anything. I know plenty of lazy, mediocre old programmers. But in order to run a project it does help to have gone through many project launches using different methodologies. That usually takes a few years of professional development, seeing fads come and go, learning to work with different personalities and, honestly, even screwing up a few times.

einhverfr 12y ago

I would agree but I would also say that good design takes a lot of time and practice to get right. You don't want to design too much up front, but you don't want to design too little. The top-level design really shouldn't be that detailed. The component design should get progressively more detailed. One of the best things programmers can do is to learn software design and I don't mean UX design but rather API design. Be conscious of what you expose to the world. Be conscious of your interfaces. Design your interfaces. Think through error conditions etc. This allows you to push a lot of component design down to the people actually doing the work. I have been instrumental in pushing my largest client at the moment from a fast programming mentality to a contract-oriented design mentality. The goal is to speed up the development of those components that need to be developed in a more agile manner by providing greater stability in a platform they can rest upon. You can't program fast if the ground changes under your feet (or rather you can but you will never get anywhere).