Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
85

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


47

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


31

You're exactly correct. This "cowboy programming" approach may get the first revision of the code out faster, but that time savings will be more than lost thanks to: Additional bugs Additional time needed to find the bugs you would would have had anyway Having to reverse engineer your code to remember what you did when you need to make a change in six ...


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

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


19

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


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

EDIT: For future reference, my answer is for another question, which has been merged into this one. It's quite out of place here, but that was not my call. She's just lazy, arrogant, ignorant and extremely selfish. This behavior is reckless. I mean, it's not that she uses an unconventional or maybe outdated methodology. She just consciously uses none. No ...


13

Code reviews. These are particularly useful as you'll be explaining the code to someone who hasn't worked on the same project so they won't have any of your assumptions about how it should work. They'll also have the added benefit of sharing knowledge around the company so when someone else has to work on the project (due to people being busy elsewhere, ...


13

We had a similar problem (without the technical details, of course) in the company I work about two years ago. You just need to do it one step at a time. Don't try to adopt the agile software development in a rush. There's a lot of stuff to learn and apply. Don't let the lack of expertise to bring you down either. Build slowly (but as fast as you can :P), ...


13

stop thinking about the code start thinking about layers, features, modules, services, and other higher-level abstractions you're getting overwhelmed because you're thinking at too low a level


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