86

Software is not a house. Intuition is good, but understand that it isn't always correct. Break down all the specs into inspection I think I will need (see into the future). This isn't accurate. In TDD, you're describing how you want to use the code. The specs say "There must be a house, with a way to enter it." The test then says "Hey, I want to have a ...


83

One of the benefits of a TDD approach is only realised when you also do emergent design. So in your first analogy, you wouldn't write 100 tests, as there's no possible way that you'll know what your software will look like. You write one test. You run it. It fails. You write the smallest unit of code to make your test pass. Then you run your test again. It ...


55

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 ...


48

It will earn the company F million pounds, over t years at a cost of x dev-days work Which is ignoring maintenance costs, support costs, the cost of sales/marketing, and makes a whole lot of assumptions about how the feature will be taken in the marketplace. But whatever; your question is clear enough about what you're looking for: How can I make a ...


46

I can point you to Alistair Cockburn's thoughts on this aspect of 'true' Agile projects: One member in the Crystal family of methodologies is Crystal Clear. Crystal Clear can be described to a Level 3 listener in the following words: “Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, ...


36

My opinion: If all you'll give the offshore people is documents and diagrams, you will have a lot of miscommunication and disappointment. My recommendation Don't give them so many documents, but rather interfaces and abstract classes in order to straitjacket them into your design goals. Require them to use a known naming standard. Require them to use unit ...


33

Making software re-usable and bullet proof is not the driving force of software engineering. Engineering is about solving real world problems optimally within real world constraints. Most engineers would prefer to work on a Ferrari - but a station wagon needs just as much engineering, and the reason a station wagon doesn't perform as well (in some ways) is ...


27

You don't have to search far to see that these practices goes contrary to the principles behind Agile. One of the principles behind the Agile Manifesto states: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. A few years ago, Scrum made a subtle but ...


26

It's called Big Design Up Front, aka Waterfall. It's not widely regarded as a highly successful methodology. But I've seen it work, and when it does work, it works very well. It's very expensive to do right. It's also what your employers have asked you to do. Offshore teams don't work the way onshore teams do. You have to be very, very specific about ...


23

You should certainly consider splitting the product into modules with interface team(s) bringing those constituent modules together into a product. This in turn would mean splitting the repositories to match the module partitioning and hierarchy. If it appears that you can't do this then the project will probably grind to a merge-induced halt considering ...


23

Yes, you're right, and if I were told what you were told, I'd run away from there as fast as possible. They're just using agile as an excuse. Sounds like the classic death march.


23

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 ...


20

The waterfall model that you are referring to was never intended to be a process model used on a real project. Instead, it is a strawman. It identifies the key phases and activities that exist in software projects and the most basic flow between them. This oversimplification of how to develop software is a flawed one, and it was even presented that way. ...


20

I don't think TDD has a problem of local maxima. The code you write might, as you have correctly noticed, but that's why refactoring (rewriting code without changing functionality) is in place. Basically, as your tests increase, you can rewrite significant portions of your object model if you need to while keeping the behavior unchanged thanks to the tests. ...


17

Actually, this bothers me. You're in a profession where you develop tools for research scientists, correct. However, you're told to make these programs quick and have them appear to work minimally. Surprise surprise. This is simply the researcher's typical approach to programming with the buck passed off to an actual programmer. The main concern here being ...


17

There's no right answer to this question because it depends on each person. If you use an iPad to do all your dev work and your clients are happy with you, you have no reason to change at all. If, however, I were in your position, I would strongly enforce the following: A version control system - While you may think an image-based development system does ...


17

Requirements will grow and change. I don't think anyone could argue that. How to collect and process incoming requests. In my experience it helps when gathering requirements if there is a single or very small group of customers acting as a filter for delivering new or updated requirements to a small group of development planners. Anyone from their side ...


16

If you are working solo. Here are the advices: Do as little low-level work as possible. Use as much library and tools as you possibly can including things you think you can easily code (don't do it, just use the library). Take the top-down approach. Only code things that you really need. When you see a problem in abstract term, search on google and use ...


16

Version control is an absolute must for any programmer even a lone one. It means you can recover simply and quickly from deleted files and complex changes that are just wrong. Basically it saves you from the stupid shit you do when you go to work hung over.


16

Maybe it has something to do with well-defined interfaces and testing, like hardware? Exactly my thoughts! Well-designed modules with clear interfaces tend to be essentially perfect. Think of something like String class of Java. It is a computer program, but it has a crystal-clear interface. There are no known bugs in it. It does what it is supposed to do, ...


16

Agile produces better results (closer to what the customer needs, not necessarily what he initially says he wants), in less time = money (or at least with more reliable estimates). It's simply a better way of conducting projects (compared to "waterfall"). Customers are happier. Programmers are happier. Projects are better. Communication is true and ...


16

The last project I was the software designer. All development was offshore. We were successful. So this process can work. I did produce a lot of documentation but it was by no means comprehensive and by no means step by step instructions or detailed down to class names, function names etc. For example, I produced sequence diagrams, use case, workflows, ...


15

It is typical to have 2 week sprints. For me, the first sprint or 2 will likely have less "visible" features than later sprints for this exact reason (for some tenuous description of "less"). That being said, it certainly should not take you 2 weeks to build your entire scaffold and have nothing in the UI visible to show for it. Maybe you do not flesh ...


14

If you are designing from a Karnaugh map, then the code may as well look that way too: // a b def actionMap = [ false: [false: { z() }, true: { z() }], true: [false: { x() }, true: { y() }]] actionMap[a][b]()


14

Waterfall model is a software development process consisting of a sequence of phases (requirements, design, construction, testing, deployment, maintenance), followed from first to last one, without going back and without using iterations (unlike in Agile models). Waterfall model helps modeling project management. Object-oriented model is a representation of ...


13

A frequent example of people gone wrong is the waterfall model. This is a diagram of the stereotypical waterfall model, which also appears in Winston Royce's paper "Managing the Development of Large Software Systems". This image is followed by this text: I believe in this concept, but the implementation described above is risky and invites failure...The ...


13

Embrace this... you see, Agile does NOT mean the proscribed ways of working are what you have to do. It means you get to decide what works for you and do exactly that. Now I'm sure, given that advice, your team will become effective immediately with the Cobol guys doing their thing and communicating with the .NET guy who'll do his thing. Hopefully they'll ...


13

The Agile Manifesto suggests that Working Software is more valuable than comprehensive documentation, and the Scrum framework takes this notion to suggest that delivering tested, working software with business value to be a requirement every sprint. Why? Well, among other things, designers and developers often fall victim to spending lots of time on YNNI (...


13

The similarities between building a physical thing and writing software are pretty minimal. That said, there's one massive distinction worth pointing out: There's a difference between "authoring a test" and "executing a test." In the example of building a house, the requirements and tests do precede the physical buildout. And portions of the test suite ...


13

In his answer, @Sklivvz has convincingly argued that the problem doesn't exist. I want to argue that it doesn't matter: the fundamental premise (and raison d'être) of iterative methodologies in general and Agile and especially TDD in particular, is that not only the global optimum, but the local optimums as well aren't known. So, in other words: even if ...


Only top voted, non community-wiki answers of a minimum length are eligible