Contents tagged with agile

  • Five things to remember when trying to change a company

    One of the recurring things I've seen at companies large and small is that they often have really great people who don't necessarily have the breadth of experience to push processes in the "right" direction. It's happening a lot less in software circles than it used to, in part because people move around so much, and they build big boxes of best (or better) practices. Still, some people will only have experience moving between suboptimal environments, some will have long-term engagements that simply don't expose them to new things, and others will be the kind of stakeholders that by default won't expose them to alternatives (specifically, small company owners).

  • This isn’t the process you’re looking for

    There was a fairly awesome pissing match between “Uncle” Bob Martin and, well, everyone, on Twitter today. Twitter isn’t a great venue for this kind of thing, because it’s hard to read and hard to make a solid point, but basically Bob suggested that you should do everything possible to make sure you have 100% test coverage. He was making the argument that this was the cheaper way to go for the long-term quality and maintainability of code (or at least, that’s what I interpreted it as, in 140 characters or less).

  • Coding rules, self-debate and formatting a string in your view

    I was thinking to myself about how I wanted to format dates in a particular project recently. I said, "Self, is it wrong to use an extension method inside a view to do this?" I was clearly distracted with something else, so I didn't answer, but then The Gu did the Twitter to this gem by a guy named Chris, and he says it would not be cool.

  • I just can't test it all

    So here's the thing about test-driven development. I think it's awesome because it forces me to be more focused in my design and I know when I break something if I have to revisit it. But I suck at it.

    I test too much or too little. Sometimes I write tests after the code because I want to get something working quickly. I don't break things into small tasks like I should, and I let big picture temporary roadblocks slow me down.

    The bigger realization that I've come to is that TDD is amazing and awesome for back-end development. When I was first exposed to TDD, it was in an environment that was 100% executing code with no UI, like mainframe replacement stuff. Indeed, this development methodology is a big deal because you really don't have any other way to understand and be sure that the code you're writing actually works.

    When you're building a Web app, especially on the considerably smaller scale involving a team of one, TDD can get in the way. A lot of the time, I want to hack out some UI and start to drive my requirements from that. And if you think about it, that really makes more sense, because the UI helps define the solution to the business problem you're trying to solve. I'm sure that some consultants would freak out hearing me say that, but it's so true. The UI is something tangible up front, not a bunch of abstract bullshit that won't actually translate to something useful.

    That said, there are a lot of cases where TDD makes sense even in this scenario, because it provides a great apparatus to make sure what you're doing works. It's great for testing (and maintaining) data access code in particular. It also works great for making sure some kind of calculation or text manipulation performs as expected.

    So as is the case with most things in life, I'm finding the all or nothing approach using a particular methodology is just not practical.

  • Iterate, dammit!

    In my relatively short career in software development (which is still like 50 years in Internet time), I've been exposed to a wide range of development methodologies, project management and general dev culture. The easy trap to fall into is trying to apply what you learn to every new situation.