New answers tagged

2

Neither approach is sufficient. It seems that each of them is clever or experienced enough to realize the short-comings of the other approach (maybe they got burned?) but fail to see the short-comings of their own selected approach... The truth is, a mixed approach is necessary: it's nearly impossible to come up with the "right" design upfront; a degree ...


4

Generally, in my experience over my career, there is insufficient design up front. And the design that does happen up front is low quality. This is Bad. Mostly because the result is (to a greater or lesser degree) throwing mud at the wall and seeing what sticks. Technical debt gets baked in from the get-go. Top-down is generally superior to bottom-up. ...


4

One note: you said Assume that you are working on a new system rather than mimicking existing ones, and thus it is not always obvious what the right end-design should look like. This is part of the problem: Unless you're working on a tiny project for an already solved problem, there isn't actually a right end-design. There's lots of possible designs. ...


5

In my opinion, they are complementary profiles and may end up doing very well. Both coding and designing are necessary phases in programming and you don't want to end up in a team where nobody wants to do X, all you need is a bit of organisation (see I can have a bold word too !) This can be done through supervision as others pointed out, but even better ...


2

What you need is a leader (or supervisor) who understands software development, and who makes the decision about which approach should be used in the project. If necessary, the leader directs the developers to work in a particular way, irrespective of their personal preferences. The only efficient solution I can think of that doesn't waste time is to ...


52

Obviously they are both wrong. The bottom up guy is hacking away at code and will never produce something that does what it is supposed to do - it'll be a continual churn as the unknown requirements are determined. The top down guy can spend just as long on architectural vision and get nothing productive done too. However, a middle ground is ideal - if ...


7

This actually sounds like an ideal scenario to me. Then again, I am both of those developers at the same time. I like to draft out the "big picture" in the form of notes that eventually find their way into an issue tracker. Then I start thinking about the implementation details from the bottom up. The big picture evolves as I gain a better understanding ...


22

The two developers need to maintain a mutual respect for each other. The top down person needs to respect the fact that the bottom up person may have come up with something that actually works. As one of my "quant" professors told me, "A working model is worth 1000 guesses." If that's the case, the top down person should consider re-doing his "design" to ...


7

You can minimize the loss of time spent by each developer if you break apart large tasks into multiple smaller and more focused ones. Have them work closely together so that neither of them get too far ahead of the other. Short sprints, and small deliverables go a long way. It's easier to fix a small mistake than a big one. It might seem counter ...



Top 50 recent answers are included