21–30 of 58 posts
Methodologies aren't a substitute for creativity or intelligence. At best they can give a person with good judgement a different angle to look at their problems with. At worst they are thought-stopping slogans that turn a gullible novice into a crippled novice.
If only management understood this. Actually, I think good managers do understand this, and do it anyway, because if you take the general case and look at it from above, methodologies do improve upon chaos.
I find that most new developers instinct is to do exactly the opposite - i.e. write the first line of their main function, then realise it needs, say, an argument-parsing class, so start writing that, then realise that needs a logging class, so start writing that, etc. which means you have to keep much more stuff in your head at once, you end up writing much more code in each commit than you should, and the distinction between bits of code at different levels of abstraction often ends up much blurrier which leads to messier design.
This seems to be quite easily countered though - just pointing out to people the difference between breadth-first and depth-first styles can have quite an immediate effect
I've found the authors proposed approach at the end of the article to be a very useful one, even if you're not using TDD. A very regular piece of advice I give to new developers is "breadth-first not depth-first" - i.e. write a whole function at a consistent level of abstraction before you dive into writing the other classes etc. you need to support those few lines of high level code. I find that most new developers…
I wish I had time to write a decent post. Lacking time, I'll try to be concise. If you want to really understand the benefits of TDD, the best book I know on the subject is actually Michael Feathers, "Working Effectively with Legacy Code". It is rather dense and getting a bit dated, but by showing you what you need to do to improve legacy code in a methodical fashion, he provides the basis for learning how to do good…
I've found the authors proposed approach at the end of the article to be a very useful one, even if you're not using TDD. A very regular piece of advice I give to new developers is "breadth-first not depth-first" - i.e. write a whole function at a consistent level of abstraction before you dive into writing the other classes etc. you need to support those few lines of high level code. I find that most new developers…
Is "top down" vs. "bottom up" programming/design really not a set of terms and concepts that is still taught in nearly every introductory programming course such that people mentoring "new developers" need to introduce the concepts and invent new terminology for them?
As a side note, I find it helpful to think of what the high level business objects will be at the beginning, but build a bunch of utility functions from the bottom up, working towards a DSL of sorts at the various abstraction levels. As you explore the solution, the end location of those functions usually becomes abundantly clear.
I've found the authors proposed approach at the end of the article to be a very useful one, even if you're not using TDD. A very regular piece of advice I give to new developers is "breadth-first not depth-first" - i.e. write a whole function at a consistent level of abstraction before you dive into writing the other classes etc. you need to support those few lines of high level code. I find that most new developers…
Is "top down" vs. "bottom up" programming/design really not a set of terms and concepts that is still taught in nearly every introductory programming course such that people mentoring "new developers" need to introduce the concepts and invent new terminology for them?
Earlier quoted context omitted.
Is "top down" vs. "bottom up" programming/design really not a set of terms and concepts that is still taught in nearly every introductory programming course such that people mentoring "new developers" need to introduce the concepts and invent new terminology for them?
It definitely is. The problem, I think, is that people forget these fundamental concepts when they're shoved into a giant legacy code base that clearly didn't follow that process. They seem to get overwhelmed by the spaghetti and forget their entire undergrad curriculum. As a side note, I find it helpful to think of what the high level business objects will be at the beginning, but build a bunch of utility functions…
Yeah I think this is a reasonable approach, especially as if you do end up completing this, and get to a design you are happy with, it will probably be very different (and hopefully infinitely superior) to your original high level design.
You've probably already heard of it but the mikado method can also be useful in some of these situations.
I've designed systems in this way before (strangely, they always seem to be some sort of document validation), and they always turn into complete hairballs of code that eventually gets thrown away and something much simpler substituted.
Now, I just stick to DRY, YAGNI, and "Compression-Driven Development" http://mollyrocket.com/casey/stream_0019.html
Methodologies aren't a substitute for creativity or intelligence. At best they can give a person with good judgement a different angle to look at their problems with. At worst they are thought-stopping slogans that turn a gullible novice into a crippled novice.
If only management understood this. Actually, I think good managers do understand this, and do it anyway, because if you take the general case and look at it from above, methodologies do improve upon chaos.
I've run teams where a very agile approach made sense (usually where the dev and users where small in number and very close) and others where a more formal phased approach made sense (usually where we need co-ordination across companies).
The simple fact is that trying to run these types of programme the same way is an exercise in futility. That's not to say that one can't extract common practices that make projects generally better e.g. it's generally preferable to get code into the wild sooner rather than later if you can do it safely, it's just that the "one true path" idea is a marketing concept not an engineering one.