Friday, December 18, 2009

Late response to "Agile is treating the symptoms, not the disease"

Ted Neward reiterated an opinion Billy Hollis shared at the Patterns & Practices summit: Agile is treating the symptoms, not the disease. The basic idea is that our current tools make software development too complex, and an agile approach is an attempt to manage that complexity.

While I agree that software development is too complex, I don't really see Agile attempting to address software and tool complexity; it's more about responding to change during the development lifecycle. With short iterations and frequent deliverables, there are more opportunities for feedback and changes in direction before a project is completed, which should result in a much better product being delivered.

I think the point that Billy was trying to convey is that there are projects out there that are small enough (or not important enough?) that it's okay if they're haphazardly slapped together; the resulting applications just need to work, but we no longer have tools that simple applications to be developed simply. The number of applications, frameworks, and libraries required to build applications is nearly overwhelming today, and there are no signs of movement towards simplicity.

Ted rephrases Billy's talk with the question "Where is this decade's Access?". Access is still around and still shipping with Office, so this decade's Access is Access. Perhaps the real issue is that nobody cares about Access anymore, so all of the non-professional developers (i.e. they don't do it for a living) don't know about it because it doesn't get any press?

I dislike Access as much as the next "professional developer" and I have seen the problems it can cause first hand. However, it still addresses an important need cheaply and effectively, and usually for quite some time before it's no longer up to the task and needs to be replaced by a more robust implementation.

Maybe there should be a revival in interest in Access, maybe...

Sunday, November 1, 2009

Make Better Software? Only if you can afford it

At the bottom of Joel Spolsky's latest blog post, Figuring out what your company is all about, there is an advertisement displayed for a new video series FogCreek has put together. It's titled Make Better Software.

It's a great idea. FogCreek is full of very smart software developers working in a great space with excellent hardware and a really smart (this is debatable for some) management team. They're so proud of their accomplishments, they'd like to share their formula for success with others through a video series describing six major areas of software development:
  • Recruiting
  • Team Members
  • Environment
  • Schedules
  • Lifecycle
  • Design of Software

Where it all falls down is the price; from now until December 1st, you can save $400 and order a set of the DVDs for $1595. I'm sure it's a bargain if it introduces positive change in how you work, how your workplace operates, or just helps get everyone on the same page. Spending less than $2000 to impact your career is better than attending a conference on the technology you're already working with.

The problem, as I see it, is twofold:

  1. Developers like myself aren't going to drop that much money on a video series for themselves, so we'll probably never get to see it
  2. Most companies won't recognize the value in such an expense (including the time investment), so they won't get on board

I can't think of a single company that I've ever worked for that would spend that much money of a set of DVDs, and most of those companies wouldn't change even if they watched them. Maybe I've just worked for the wrong set of companies over the course of my career. But maybe, just maybe, FogCreek doesn't realize the gap between themselves and nearly everyone else. Even worse? What FogCreek does realize the gap, but most companies just don't care?

Personally, I'd love to go through those videos, but chances are really good that I never will.

Thursday, August 6, 2009

Negative Testing

Disclaimer: I realize my statements are generalized, and might be completely off base, but they match my experience and even if they are wrong, illustrate the critical need for a mindset required for writing good unit tests.

In their most recent podcast, Joel Spolsky and Jeff Atwood broach the subject of software testers, and how they address a different concern in software development than unit testing. The fundamental thought is that software developers chip away at a feature until it works; testers chip away at a feature until it breaks.

The problem with most unit tests written by software developers is that the goal only verifies that things work under ideal circumstances:
  • All the CRUD operations work!
  • All the business rules are enforced!

Most unit tests typically fall down because the haven't anticipated all the problems that will occur in more realistic scenarios. For example, when was the last time you've seen a unit test that verifies the length of text fields? As Joel and Jeff mentioned, even if you have some negative testing, have you verified your code works with Unicode? In other languages?

I've been guilty of validating input, but still missing the mark. Several years ago, I was working on an application that was using regular expressions to insure that integers were being entered by the user for a given field. In the first round of testing by QA, one of the bugs reported was that I was accepting negative values when only positive values were valid.

The hard part for most developers, including myself, will be in changing gears from getting our code to work to making it break. Unfortunately, the only way I know how to make this come easier it to take a lot of pride in your work, learn from your mistakes, and do your best to avoid repeating the same mistake twice.

Finally, while I don't want to spend a lot of time on the value of QA, I would like to at least echo Joel's expressed value in having a human making sure your code works. In addition to functional validation, real live people will also provide usability, performance (sometimes), and general workflow feedback, which is invaluable to creating a great user experience for your users. Think of them as someone asynchronously pair programming with you rather than being at odds with them.

Tuesday, July 28, 2009

Late 2009 Software List (Mac)

Following right behind my list of standard Windows applications I have installed, here is my list of developer tools, utilities, and general purpose software I have installed for Mac OS X.

  • SubEthaEdit: Great text editor that includes revolutionary collaboration support through Bonjour
  • TextWrangler: Free text editor for Bare Bones Software; subset of their BBEdit product
  • TextMate: Powerful text editor used by the Ruby on Rails team
  • Xcode: Apple's IDE; bundled with Mac OS X, but not installed by default
  • Safari: Apple's built-in browser, and my personal favorite
  • FireFox: Fully featured and extensible browser; very popular for its features and standards support; you'll probably want to install FireBug, a web development plugin for FireFox
  • VLC media player: Plays every file I've ever thrown at it, with a minialistic and Mac-native interface
Office Suites
  • Office 2008 for Mac: I got a great deal on Black Friday 2007, otherwise, I wouldn't have a copy; it is nice for working with the latest native Microsoft formatted documents
  • iWork: Consists of Apple's word processor (Pages), spreadsheet (Numbers), and presentation software (Keynote); great for the price, and does everything I need it to
I didn't include a utilities section this time, because OS X comes with a plethora of small application. Here's the list of bundled applications I have in my Dock:
  • Dictionary
  • Calculator
  • TextEdit (defaulted plain text mode)
  • The whole iLife suite (iTunes, iPhoto, GarageBand, iMovie, and iWeb)
  • DVD Player
  • Time Machine
  • iSync
  • Software Update
  • Activity Monitor
  • Console
  • Network Utility
  • Terminal
I've also trimmed my Dashboard widgets down to Weather only.

The only other observation I'd like to make is that besides having the OS come with more applications, the applications I do pay for are a lot cheaper altogether than the applications I pay for on Windows.

Monday, July 27, 2009

Late 2009 Software List (Windows)

Inspired by Scott Hanselman's Ultimate Developers and Power Users Tool List for Windows (the latest version I could find was 2007), I'ved decided to create my own. FYI, I'm running Windows 7 (64-bit) on a Mac Pro.

Update: You can find my Mac list here

Development and Design


  • Internet Explorer 8: Built into Windows or available as an upgrade; be sure to upgrade to version 8 if you haven't already!
  • Google Chrome: Google's browser; fast and small, but lacking in extensibility; I'm also subscribed to the Dev Channel, giving me frequent auto-updates
  • Mozilla FireFox: Fully featured and extensible browser; very popular for its features and standards support; you'll probably want to install FireBug, a web development plugin for FireFox
  • Safari: Apple's browser; allows for Mac and iPhone compatility testing, since all of Apple's version are based on WebKit; version 4 plays much nicer with Windows


  • uTorrent: The best and fastest torrent client out there
  • 7-zip: Open source zip file utility; integrates nicely into the shell
  • Adobe Flash Player: Only on the list for youtube and the occasional game trailer
  • Foxit Reader: The free and best PDF viewer out there; dump your Adobe Acrobat garbage immediately if you haven't already


  • QuickTime: Yes it's slow and doesn't play nice on Windows, but the video quality is good, and there are a lot of movie trailers on Apple's website
  • iTunes: Only installed to get MP3s on my iPod
  • PowerISO: Great utility for creating and extracting .iso files; supports CD/DVD burning too
  • VLC media player: Plays every file I've ever thrown at it, with a minialistic interface


  • Windows Live Messenger: While others are available, supports what I need without much fuss after some tweaking
  • Skype: Free voice-over-IP (VOIP) client; you can upgrade your account to make phone calls too
  • SharedView: Screen sharing application from Microsoft; very handy for remote folks


  • WinSplit Revolution: Great utility for moving/resizing windows; includes quite a few defaults and can be customized

Office Suite

  • Office 2007: Includes Word, Excel, PowerPoint, Outlook, and others, depending on the version; if you can't afford Office, don't want to pay for Office, or don't care for the ribbon interface, give OpenOffice a try

Friday, July 17, 2009

The Essence of Software Craftsmanship

Alan Stevens gave a great talk at the Nashville .NET Users Group last night titled "The Taming of the Code". One of the points he got across what that trying to explain good software engineering principles to new or stagnant developers on your team is really hard. And it's hard for a few reasons:
  • The terms can be strange and hard to remember (The Liskov Substitution Principle)
  • The principles themselves will seem theoretical to those that don't grok them immediately
  • Measuring the value of good engineering is next to impossible, so a bunch of rules without good justifcation probably won't happen

Alan's talk wasn't specific to these points, but seemed to acknowledge the difficulty in the expression and adherence to good engineering principles. The way he thinks you can get around such problems is by distilling them down to their fundamentals:

  • Don't repeat yourself (DRY)
  • Separation of concerns

I agree 100%. It's tough to argue against DRY, and when followed, eliminates a lot of bad coding practices immediately. While separation of concerns is a little harder to explain, the metaphor Alan used to explain it was seams within your application. A great quote he referenced from Jeremy Miller was something along the lines of "I don't try to figure out how to write code any more, now I try to figure out where to put it". The SOLID Principles have a bunch of rules that help guide you into putting code into the right places, but by just saying that all business rules are enforced behind the seam of the business classes gets the point across easier. I think taking the approach of streamlining and simplifying our communication within the community could go a long ways towards improving the craft overall.

I see a lot of potential in communicating and adhering to the two principles Alan has boiled things down to.

Tuesday, July 7, 2009

"Safe" Choices

In my previous post, "Dangerous" Choices, I discussed the reasons why some of the more vocal members of the programming community advocate technology choices that are emerging. At the same time, today's most popular choices are considered somewhat boring, uninspired, and unexciting (since everybody's doing it). There are, however, a few things they got wrong:
  • Technologies like C# and Java are being constantly updated with new language features and technologies (LINQ, MVC, Silverlight, Hibernate, Spring, etc)
  • My own personal experience shows that under the right circumstances, you can work at a great place doing work that pushes you in technical directions you haven't been in before
  • Trying to switch technology stacks is difficult if you're not in the first wave of switchers, since you'll lag behind everyone else in experience, making your job search more difficult, as the pool of resources is smaller and their expertise is generally higher

I'm a C# developer by day, but play around with Ruby on Rails and Groovy on Grails at night. While it's true that C# is missing certain language features like duck typing and closures (although anonymous methods and delegates fill that gap in faily well), it's a language that has evolved signficantly since its first release, and it quite a capable language for most applications being developed. Between LINQ and the new MVC framework, there is little that other platforms can offer that are truly compelling (unless, you insist on avoiding Microsoft technology altogether, which is a close-minded and bigoted mindset in my opinion). In fact, I would argue that using the Microsoft technology stack is actually the more productive choice, given the tooling.

Visual Studio's intellisense, while often frowned upon, makes the .NET framework far more accessible than Grails or Rails, due to the discoverability of methods and properties. If I'm not sure what methods are available for strings, just typing a dot gives me a wealth of information. Yes, editors like Eclipse and IDEA are getting support for some of these budding technologies, but today, you have to rely heavily on documentation.

Then there's debugging and compilation. Hey, I'm a fan of static langauges, if for no other reason that the compilation feedback I can get. I don't have to take seconds/minutes to run unit or integration tests to see if my last commit is syntactically valid. I've also got a nice debugger that will let me step through the code without resorting to printing output to the console. Again IDE support will improve things for Grails/Rails, but it's not fully baked today.

Finally, I want to address the job market. There are great companies out there in the Microsoft space doing exciting and cutting edge work. Take Vertigo, Wintellect, and Thoughtworks (yes, that Thoughtworks). They're all doing large and small projects using the latest and greatest stuff. I'm sure that there are many other good companies out there with a great group of developers coding against the newest stuff.

In fact, if I had to define what I really believe "safe" versus "dangerous" to be, it's more about how soon you're willing to adopt new technologies, not what platform you're on. I've worked for some pretty big companies in the past, and I always found frustration in their reluctance to move to new offerings at a reasonable pace (over a 3 year wait on .NET, for example).

Don't get me wrong, if you want to work with some of the industry's current luminaries, you'll have to broaden your horizons beyond Microsoft, but in so doing, you'll probably pick up some things up you've never thought about if you don't anyway. Or worst case, you might be able to glean some wisdome from folks who have been doing it that way for years before Microsoft provided their own branded version. And since you're programming because you love it, wouldn't you love learning something completely new? The pragmatic programmers often instruct learning a new language a year to expand your horizons, and that's a good thing. Just don't turn your back on C# or Java because you've been doing it a while; there's still plenty to learn and new frameworks popping up all the time that expose something new to learn too.