5 ms·
Not much planning. Direct contact with the people who use the software. Good coding practices, preferably TDD. No time pressure. This is pretty much agile how i
by cjfd 5y ago
Not much planning. Direct contact with the people who use the software. Good coding practices, preferably TDD. No time pressure. This is pretty much agile how it should be in theory but not in practice. Agile in theory is actually a very good development process. Agile in practice tends to be a bit worse. Waterfall always is the hell. My boyfriend is at the moment doing waterfall development. He hates it. So much useless paperwork.
- aaaaaaaaaaab 5y agoYeah, that’s fine for developing the new landing page for the company website. Not so much for developing mission critical systems.
- cjfd 5y agoI disagree. Among the things that I listed was TDD. If one practices that consistently one can create highly reliable software. In fact one might argue that using TDD for the new landing page for the company website might be overkill. Maybe you do need a bit more planning for your 'mission critical system' in order to perhaps attain performance goals. However, I will tell you here and now that if you just do TDD for your mission critical system and you do it well you will already be better than most programming going on for so-called missions critical systems in many, many places.
- iratewizard 5y agoTDD is cargo cult.
- cjfd 5y agoIt really is not. TDD is for highly competent programmers.
- aaaaaaaaaaab 5y agoLol, not really: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
- dragonwriter 5y ago> TDD is cargo cult. No, but like any practice that becomes known of outside a narrow group of highly-competent, highly-motivated experts in the relevant area, TDD can be (and often is) cargo culted. It is thus often the case that people's only practical contact with “TDD” is with a cargo cult application of it.
- cjfd 5y agoThis is true. The most important way in which TDD can turn into a cargo cult practice is to test every class and every method separately. This then turns into the testing of implementation details that are very much subject to change. It can also lead to the testing of trivialities, like 'can the standard library of my language still add elements to a container'. One should in most cases write tests about somewhat higher level properties of a system where the user might actually recognize the tests as being about stuff that they value. In most cases one would write tests about a small set of closely related classes. There should also be tests about somewhat larger clusters but there should be fewer of them because they tend to be more brittle and have worse performance.
- mbrodersen 5y agoAgree. Automatic system/user level testing is awesome. Automatic unit/module/class testing is a waste of time.
- iratewizard 5y agoAnd here come the cultists to tell me it's not a cult. TDD is at best training wheels for an incompetent junior developer. All of the TDD cultists I've worked with in the past have needed a lot of extra hand holding in how to properly design architecture, how to write more legible code and have never been allowed to go anywhere near interface design or development.
- mbrodersen 5y agoAnything taken to extreme is a problem. Too much water will kill you. Not enough water will kill you. System level automatic testing has saved me hundreds of hours of work. And years of enjoying zero bugs in production. However I achieved that with zero unit testing. System level testing only.
- yyyk 5y agoTDD is an implicit repudiation of Agile. One of the principals of the original Agile manifesto was "working software over comprehensive documentation". After all, a test is a form of documentation, albeit one that is more suited to a programmer's tastes. Agile places software and documentation at opposition - TDD tries to tie them together.
- dragonwriter 5y ago> TDD is an implicit repudiation of Agile. TDD was developed in the 1990; Agile was articulated in 2001. Were they actually opposed, “Agile is a repudiation of TDD” would be more defensible. But your basic premise is wrong... > Agile places software and documentation at opposition No, the “X over Y” statements in the Manifesto aren't about opposition, they are about subordination. ”over” can be substituted with “should shape the use of” rather than “should exist instead of”
- yyyk 5y agoYou're right about the historical chronology, but TDD adoption IMHO came much later, after Agile exploded in popularity. Maybe it's just my neck of the woods, but I heard of TDD only much later. As for the "X over Y" statements, well, it's a rhetorical style which definitely creates an implicit opposition. Subordination makes no sense here. Our job and the business value is in working software, of course we want that most of all. Why mention it over something unless that something is in the way and we want to discourage it? Let's say I told people "Crossing the road over obsessively looking at both sides of the road"*, and kept referring to "obsessive looking" while barely mentioning people should look at all. As guidance this is horrible, for reasons I believe are obvious. If I said later "I only meant obsessive looking" and "you should adjust your crossing process so it suits you" it wouldn't make my advice right, would it now? * Documentation is of course much less necessary, I'm just taking an extreme example to show the rhetorical style.
- Jtsummers 5y ago> That is, while there is value in the items on the right, we value the items on the left more. The value of the items on the right (per the manifesto, if you disagree on the relative values that part can be debated) is lower than the value of the items on the left, but it is not zero or negative.