Wednesday, February 28, 2007

The Art of Agile Development - automation

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/the_art_of_agile_development__automation.htm]

James Shore, a huge agile leader, is writing a book The Art of Agile Development. He's previewing chapters to get user feedback. His chapter Reply On People encourages developers to play to their strengths. He had a good point on automation, to paraphrase:

Most people don't like repeating tedious tasks, but many devs would find it a creative challenge to automate that same task. It's a good way to show how automation is a win from so many angles - more interesting for the developer, more effective in the long run.

 He's obviously got a lot more gems in that book; I look forward to it getting published.

Monday, February 26, 2007

Good book: The Pragmatic Programmers

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/good_book_the_pragmatic_programmers.htm]

I recently finished a good book, The Pragmatic Programmer, by Andrew Hunt and David Thomas. (I had read their Unit Testing book a while back).

What I liked to much about it was that:

  • It really was practical
  • Andy and Dave are good writers, with a down-to-earth style
  • It transcended the current technology (much like Code Complete)
  • It addressed a huge range of topics, from automation to testing to team culture. Software engineering isn't just about a lone-wolf developer typing the write code. Rather, it requires a huge breadth of skills and process.
  • It boiled things down to specific tips.
  • It pretty much takes a bunch of lessons that I learned the hard way and presents them.
  • It's short - maybe 250 pages (not including appendix, references, etc...)

I wish I had read this five years ago.

Monday, January 22, 2007

What would it take to be twice as productive?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_would_it_take_to_be_twice_as_productive.htm]

Often you can improve the future by learning from the past. Given that we always want to be able to develop faster (given the same level of quality, energy, etc...), it merits reflecting on the question: What would it take to be twice as productive?

Here are some general ideas I was thinking about:

  • Better tools (like a CodeGenerator or Resharper)
  • Better hardware - a fast machine, dual monitors, perhaps even a spare virtual machine that you could upload code to to run long-duration tests without blocking your main dev machine.
  • Reusable components - business logic, validation, UI components. No need to waste time re-inventing the wheel.
  • Knowledge transfer - like having a good, quick wiki, or technical/domain experts to trouble bottlenecks
  • Prevent and handle regression testing - such as code reviews to ensure higher quality code, as well as comprehensive suite of automated unit tests
  • Better automation - ideally you can automate anything tedious that steals your time, like checkouts, tests, code generation, continuous integration
  • Taking time to think first before coding - i.e. "code now, fix later" is more than just a moral killer, it also kills the schedule

There's a lot of things that are more standard, that I'd hope any developer would have:

  • Good source control system - no one wants to waste time because they lost their code, or had a merge error, or can't track something down
  • Issue manager system -
  • Good project management to coordinate the team and give everyone clearly defined goals.

There's obviously a lot more. What would make you a faster developer?

Friday, January 5, 2007

Free online JavaScript formatter

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/free_online_javascript_formatter.htm]

Sometimes you'll see JavaScript in what appears to be a garbled mess - no spaces, comments, or line breaks. This may be because JavaScript is transmitted over the wire, therefore it's faster performance to omit all those things that are unnecessary to the end user. However, they're great for the developer trying to read someone else's JavaScript. Hence, the need to format JavaScript.

There are several free formatters out there. Criteria I'm interested in is: (1) Accuracy, (2) Convenience - ideally an online tool as opposed to something I need to download, (3) Cost - ideally it'd be free, and (4) Length - I'd want it to be able to format large scripts, not just some 5 line demo.

There seems to be a lot to choose from: http://www.google.com/search?hl=en&q=JavaScript+formatter

Currently I'm looking at: http://www.jwmdev.tzo.com:8080/resources/js-tools/index.html

I'm also finding the NotePadd++ language feature helpful with this because it (1) color highlights JavaScript, and (2) match thes parenthesis and brackets for you (including nesting), making it very easy for you to format it yourself as you run through what the code actually does.

Thursday, January 4, 2007

MassDataHandler article in .Net Developer's Journal

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/massdatahandler_article_in_net_developers_journal.htm]

Paylocity recently published an article about the open-source MassDataHandler. This framework assists with testing the database.

We've also uploaded version 1.3, which offers several new features:

  • Improved handling of identity values and triggers: (1) Triggers no longer break the identity inserts, (2) You can specify identity inserts for a table-by-table basis using an Xml attribute on the Table element, (3) If you set IdentityInsert=On for a table without Identity, then it no longer crashes.
  • Improved extracting from existing data: (1) The Existing Data tab can now use a custom select that returns many tables, and (2) When using Existing Data tab, if you use a Custom filter, it will copy your Sql select values into the Xml file as a meta node.
  • Some miscellaneous bug fixes and enhancements.

You can download the framework on Microsoft's CodePlex site.

Tuesday, January 2, 2007

How Old is Legacy Code?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_old_is_legacy_code.htm]

Most developers like to write their own, new exciting code. However, the reality is that often you deal not with new code, but rather existing "legacy" code. How old does code need to be before it's considered legacy? Some people say just a few minutes - you type code, you go get a snack, you come back, it's now legacy code. I don't think this is fully practical. Rather, here are some general guidelines that I personally find helpful in deciding if something is legacy code or not:

  • Is the original author no longer available? - Nothing makes code seem more legacy than when you no longer know who wrote it.
  • Is the code already in production? - Once code is in production, there is a definite contract and expectation that you need to adhere to.
  • Is the code to big to just throw away? - If the code is small enough that you can just throw it out and restart, it's not really legacy yet.
  • If it's your own code, have you forgotten it? - Even if you wrote the code yourself, if you've done several things since and therefore no longer remember it, it seems more legacy.

In summary, legacy code implies it's already in production, or it's too big to throw away, or you have to re-learn what the code does (because either the original author is gone, or you can't remember it). Throw-away code that you wrote five minutes ago which isn't used by anyone else isn't really legacy yet.

Monday, January 1, 2007

Paylocity is hiring a QA engineer

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/paylocity_is_hiring_a_qa_engineer.htm]

If there's any sharp QA Engineers in the Chicago, IL area looking for a new job, my company, Paylocity (http://www.paylocity.com/) is hiring. This is a good environment - little politics, vibrant and growing company, great team chemistry, and a ton of learning and growth opportunities. We're a .Net development shop, primarily working on an ASP.Net 2.0 web application that assists clients with Payroll. I'm a developer, and from a developer's perspective, the ideal candidate would have a technical and automation background, and would be comfortable with questions like:

  • How would you test the function IsEven (check here for some ideas)?
  • How would you test Notepad or Excel?
  • Have you ever needed to set up your own performance or UI testing framework?
  • Do you like using tools and technologies to simplify and automate testing? Which technologies do you think are good for QA testers to know?
  • How can you improve a process to reduce testing time (such as using automation for regression testing)?

QA engineers are vitally important, and there's so much more to good QA testing than repetitively clicking away at a website. For an opportunity to be part of a great team, just send an email to  tims#@#paylocity.com (remove the '#").

UPDATE: Description moved to here