On 19 Jul 2013, at 21:01, Graham Ashton <[email protected]> wrote: > Sometimes though, you want to advocate is a move away from a current > practice. How do you go about doing that?
Ship code. There are three important parts of writing software well as a professional (you can skip either or both of the first two if you're an amateur or for a tool you never intend to release): 1. Listen to stakeholders and ask them to develop their thoughts to aid you in clarifying your own. If they're good, they'll want to write software that tests a hypothesis, and work with you on measuring results. Rare, but that's the ideal. 2. Think hard about the right way to solve the stakeholder's problems using the languages, tools and experience you have to hand. You can go back to texts, whitepapers and examples from other languages you're less familiar with to help form your ideas. It is better to spend 2 hours thinking and researching and an hour coding than it is to spend 3 hours hacking. 3. Write code according to "best practice". That bit in quotes can be a killer, but let's suppose for now we agree as a minimum it includes writing tests, DRY, good refactoring practices, releasing early and often, etc. If you just do the first one, you're a sales person, not a developer. If you just do the first two, you're an academic, not a developer. If you want to talk to developers about developing, you have to do all three. Developers who tell other developers they're doing it wrong without shipping code are just whiny bitches. If you don't believe me, go and tell the core team of any open source tool or framework what they're doing wrong by referencing some textbooks or academic papers. Some will take a while to get there (the OpenBSD team will get there very quickly and bluntly), but all eventually will get to the same point: ship code, or please shut up. I didn't use to get this. I used to whine without shipping code and people hated me for it. Now I understand why. I appreciate the irony of making my argument here without any code to support it, but then I'm not the one saying everything has to change. :-) However, If YOU think part of Rails is wrong, fork, refactor, issue a pull request. If YOU have a better idea of how to build applications that guides developers into more structured thought processes, build a framework to allow them to do that. I'd really enjoy trying it. Here's a cut-out-and-keep guide to changing the World: 1. Write and ship code 2. Let others write and ship improvements to that code 3. Learn 4. GOTO 1 # Not considered harmful > What strikes me about the Ruby community is that we're a very fashion-lead > bunch. It seems as though new projects get adopted simply because they're > there and they look cool, not because they're better (in a business context) > than what came before. Sometimes they're worse, but the Ruby community adopts > them as a new default anyway. > > We don't seem to be very discerning. We lack taste. Ruby is a community dominated by developers who are interested in trying new things. In my experience, Ruby developers have most - if not all - of the following traits: - Self-taught at a youngish age, already able to do relatively complex software development by the time they're leaving school or going to University, and therefore see development as a hobby they're lucky enough to get paid (quite well as it happens), to do professionally. You don't see as much passion from a young age in other communities (e.g any Java shop where ties are the norm). - Pretty committed to http://agilemanifesto.org/ and in a wider context the Lean Startup mentality - Rationally-minded and open to new ways of doing things and trying new approaches providing they can test hypotheses experimentally and add that learning back into the process With that in mind, they are going to prefer working software over a philosophical discussion, and if somebody ships some software and says "This is my answer to why I think we're doing X wrong, and here's how it deals with it", then the Ruby community are probably likely to give that tool some time and space and maybe use it on a project or two to test the author's hypothesis and share their learning from it. What works well in practice, tends to stick. What works well for person A might not be what works well for person B, so they might argue about it, but in reality it's up to each developer to make those choices with their team, because the reason why it worked for one and not the other might be caused by context. Good developers will understand what worked for them in one context might not work in another. They will be flexible, and realise that they might need to use tools they disregarded in other scenarios because it is now more appropriate. Bad developers hate on tools and processes because they see the World as black and white and all development problems as being solvable with identical processes. As a CTO I am frequently in the unenviable position of breaking ties where there is disagreement and trying to coach developers into how to make better choices within a wider context. If the project is a small project to produce a code base we expect to see running in production for a short period whilst customers make up their minds, I don't care what specific tools developers use providing we have highly-refactorable code that can be maintained, expanded upon and reused as much as is practicable without us spending all our time building frameworks. If the project is for something I expect to see running in production on an important project for many years to come, I want gems with a major version number > 0 across the stack. I want to see there is some maturity in the tool choices we make. I want consistency, and I will take into account factors such as staff recruitment and training, TCO where calculable, etc. That means in the teams where I work at least - and I think this is common within the community - we are not actually led by fashion or fad, but by experience and a desire to improve how we go about doing what we do. Our industry didn't exist a century ago. We're still a pretty young industry working stuff out. It's OK to feel our way and try new things, and understanding context matters is valuable. > But back to my point. Cucumber is the most expensive (to use, in actual > pounds) testing framework I've seen since Fitnesse. It doesn't do anything > that can't be done more cheaply test-unit. Not a thing. [citation needed] - Show us hard numbers. That doesn't tally with my experience (or that of many others), of people who are using Cucumber for the right part of the right job. > I've still not met a product manager who gets excited about reading the > scenarios, though I've spoken to a few who've been brainwashed into thinking > they should If scenarios are written in such a way where product managers are actively avoiding reading them, they're probably being written incorrectly. Cucumber tests are - in part - a method to agree that developer and stakeholder understanding and intent are clear and unified. The feature files should be concise and to the point. If a scenario has more than half a dozen steps or so (it can have as many examples as you need as multiline step arguments), it almost certainly needs refactoring. I've seen people insist no scenario goes beyond 3 steps, but that can lead to scenarios as obtuse as those containing 20 steps to my mind. And whilst product managers might not jump for joy at reading Cucumber tests, can you honestly say that those same managers would rather read unit tests? Probably not. What about inaccurate documentation that is out of date and doesn't represent what is actually implemented? Probably not either. So what you're actually saying is they don't want to read tests, even though they need to. But if the tests are the active, accurate and up-to-date product documentation, and they're the product managers, what does that say about them professionally? Just because a product manager is bad at their job, it doesn't mean the developer is being bad at theirs by trying to do the right thing and encourage use of Cucumber to communicate and document product functionality. > RSpec adds zero business value over and above test-unit RSpec vs test-unit is effectively a matter of taste, and I haven't had the problems you have had, or not to the point where I'm prepared to stop using RSpec. All I'd say is if your arguments for test-unit are basically the same as DHH's, you should remember that DHH's stakeholders are probably not like yours. > yet comes with an obtuse API that developers have to waste their time > learning. So does Java, but that doesn't mean it has zero business value. :-) > - Writing far too many tests (I see this everywhere) That normally means they're not writing the right tests. > - Writing their tests in RSpec and Cucumber There is nothing in my experience to indicate that a competent user of those tools is going to spend more money than if they were using other tools. Quite the contrary. > I reckon we could save (globally) millions of dollars in lost resource per > annum if we changed the Rails community's approach to testing. It needs > education and good judgement, not a new project. Great. Ship code. Write a demo app using nothing but test-unit, and then reimplement it again using RSpec and Cucumber and show us how the latter got you in an expensive mess. Put it on github, and let us take a look. Us fanbois might see where you've gone wrong and explain to you where a lack of experience around Cucumber and RSpec let you down, and show you how to use those tools in a better way, and then you might see how in those contexts that they are very suitable tools. Or you might make us all see the error of our ways, and we'll jump ship over to test-unit. -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/groups/opt_out.
