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


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


19

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

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


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

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


16

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

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

For Scrum, Ken Schwaber and Jeff Sutherland explain: Daily Scrum The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily ...


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


13

What you're describing in mathematical terms is what we call painting yourself into a corner. This occurrence is hardly exclusive to TDD. In waterfall you can gather and pour over requirements for months hoping you can see the global max only to get there and realize that there is a better idea just the next hill over. The difference is in an agile ...


13

What you hear about is mostly Scrum. And Scrum doesn't deal with technical practices. And many consider that a failing of Scrum, as adoption of Scrum without adoption of proper technical practices results in "Flaccid-Scrum". eXtreme Programming, which is much less known and adopted Agile practice, on the other hand does deal with technical practices great ...


12

I know you're trying to avoid this, but the real insight here is to realize that something is seriously wrong with your codebase: you need to run a full suite of tests that takes a week just to be sure your code is stable! The most advantageous way to fix this problem is to start separating your code base and tests into (independent) sub-units. There are ...


12

Disclaimer: I am not a video game developer. But I do have a "hobbyist" interest in it. Most of the AAA games you see are made using Engines. They aren't written from the ground up. Think of an engine like a framework. You have .NET framework, Java SDK, Cocoa toolkit. All things to make your job of creating software easier and abstracting away the kitchen-...


12

The question you should ask yourself is how is the salesperson know that the feature will cost x developer-days of work. Given that even good project managers with years of professional experience cannot often tell that, such data coming from a salesperson seems extremely... speculative. According to my experience, salespersons usually don't make estimates, ...


11

There is one key thing that may make this acceptable: the team accepts the scope of the sprint. In Scrum, teams don't just get assigned work. The product owner negotiates with the team to prioritize product work and technical (debt) work. The project manager, product owner, and team then negotiate on what gets pulled into a sprint and what the scope of that ...


11

When CSS Variables were introduced, there needed to be a syntax that does not clash with existing CSS versions, and allows future CSS versions to declare new properties. Properties that begin with a double-dash won't ever be used by CSS itself, so they can be used by other people. Since these custom properties aren't declared with any new syntax, they are ...


11

You have fallen into the trap of believing the nonsense idea that writing software is analogous to building a house. It isn't. It's more analogous to creating the architects drawings and the structural engineers calculations. Now with real houses, the architect creates those plans up front. Then you call in the builders, who start building, run into ...


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