http://www.bennorthrop.com/ Ben Northrop Blog Thu, 29 May 2008 17:25:12 GMT en-us http://www.bennorthrop.com/Essays/2008/program-to-interface-not-implementation.php http://www.bennorthrop.com/Essays/2008/program-to-interface-not-implementation.php Thu, 29 May 2008 17:25:12 GMT I need to butt heads with conventional coding wisdom for a minute. We've all heard that it's good to program to interfaces and not implementations, but I'd like to argue that in most cases this actually buys us very little. In fact, it often just causes code bloat and developer frustration. There, I said it! http://www.bennorthrop.com/Blog/groovy_builds_with_gant.php http://www.bennorthrop.com/Blog/groovy_builds_with_gant.php Tue, 29 Apr 2008 17:25:12 GMT I've been looking into Groovy lately, and I'm really impressed. The language is powerful but concise, the tool support and documentation seems good and getting better, and the community is growing. The problem is, in an enterprise environment, I have no idea where it actually fits in. I don't think it makes sense using it for any large-scale system, at least for now - weak typing scares me in team environments...and in general it's just too bleading edge. So what else? Well...I recently read Groovy-powered automated builds with Gant, and I think the case here is strong. Groovy could make a lot of sense as a replacement or complement to Ant. After a few hours of playing around with Groovy, Gant, and AntBuilder, here's my humble assessment. http://www.bennorthrop.com/Home/Blog/deliberative_development.php http://www.bennorthrop.com/Home/Blog/deliberative_development.php Rri, 22 Apr 2008 17:25:12 GMT In arm chairs across American universities, philosophers are pontificating on the merits of a relatively new theory in political philosophy: deliberative democracy. This essay explores this theory, and trys to glean a few key insights for software development... http://www.bennorthrop.com/Home/Blog/unit_testing_daos_and_database_code.php http://www.bennorthrop.com/Home/Blog/unit_testing_daos_and_database_code.php Rri, 21 Mar 2008 17:25:12 GMT I don't care what all the tutorials say, unit testing in the real world is tough. Well, let me rephrase that. Creating a unit test is easy. Creating a repeatably-passing unit test is not. The problem is, just about all enterprise applications are dependent on an external database, and while a database itself isn't anathema to unit testing, the data inside it is. The reason is that, unavoidably, unit tests of an enterprise application must refer to specific data in order to test functionality, and this specific data is susceptible to change. What typically ends up happening is that earnest developers create unit tests that work at time t, and then at t+1 the underlying data has changed and subsequently a seemingly random assortment of unit tests fail - the ones that depended on the exact data from time t. Ouch. The inevitable fall-out is that developers must then either (a) investigate the failures and fix the unit tests, (b) delete the failing tests, or (c) live with something less than 100% passing unit tests. Not a good choice in the lot. http://www.bennorthrop.com/Home/Blog/2008_02_08_politics_and_programming.php http://www.bennorthrop.com/Home/Blog/2008_02_08_politics_and_programming.php Wed, 12 Feb 2008 17:25:12 GMT So you're a conservative. Or maybe you're a liberal. Or libertarian. It doesn't matter. The point is you have some beliefs about the political system; that is, beliefs about the rights, roles, and responsibilities of governments and its citizens. You also have beliefs (perhaps equally strong) about software development. You favor quick iterations, formal requirements documentation, code reviews, or offices with doors. The question is, what do these beliefs have to do with each other? Does you being a conservative or a liberal have any relationship to you being an "agilist", or Java guru, or refactoring zealot? In other words, is there some hidden correlation or correspondance between the two sets of beliefs? And if there is, what would it tell us? How would it help? Well, this is something I'm curious about, so I've created a very simple and unabashedly un-scientific survey to test this query. If you'd like, take the survey and see where you lie on both the political and software development spectrums...and then check back in a few weeks or so when (knock on wood) I'll have a reasonable sample size and will have analyzed the data and extracted some amazing, insightful correlations that will shake the very foundations of the software development world. Or not! But in any case, please be assured that I have *no* hidden agenda here - you can count on no such specious arguments: "liberals love unit testing, unit testing is great, therefore liberals are great". This is just an intellectual curiousity about how political beliefs shape professional beliefs. I have some hypotheses, but don't want to bias the results - so again, check back. Thanks! http://www.bennorthrop.com/Home/Blog/2008_01_20_decision_tree.php http://www.bennorthrop.com/Home/Blog/2008_01_20_decision_tree.php Wed, 06 Feb 2008 17:25:12 GMT Most architects and developers are familiar with this fork in the road: Your system needs to do X now, but in the future it may need to do Y as well. Knowing that X and Y are closely related, do you spend a little extra time now and design X in such a way that adding Y in the future would be easy? Or do you keep things simple, focus on the more pressing X now, and ignore Y until the day when you really need it? http://www.bennorthrop.com/Home/Blog/2008_01_04_pmdreports.php http://www.bennorthrop.com/Home/Blog/2008_01_04_pmdreports.php Fri, 04 Jan 2008 17:25:12 GMT "If you cannot measure it, you cannot improve it." -- Lord Calvin If you've used PMD, you know it's a very helpful Java source code analysis tool for improving code quality. Integrated into your IDE, it can point out in real time common stylistic and semantic coding mistakes; things that will, in aggregate, reduce the maintainability, extensibility, or overall quality of the system if not addressed. Even more, it can also be used both as a teacher, disseminating best practices to junior developers, and a code review facilitator, reporting nit-picky "braces and spaces" issues in your teammates' code so you don't have to (which, I'm guessing, is why PMD's motto is "don't shoot the messenger"!). Essentially, as a developer tool, it's extremely useful. The problem is, however, that as an architectural tool, that is, as a tool that effectively helps stakeholders understand and manage code quality at a system level rather than source code level, PMD alone is fairly powerless. Though it provides excellent, raw code quality data, it has no real mechanism for helping developers and architects understand the bigger picture: is code quality overall improving or degrading, which components in a system have the worst code quality and will therefore be tougher maintain, and how does code quality in our system compare to industry standards. PMDReports, a simple, open source reporting engine wrapped around PMD, was designed to this end, as a tool to help developers and architects understand and then improve code quality at a system level. Run either manually for a quick quality assessment or hooked into a build and run recurringly, PMDReports will store code quality metrics from PMD in a text-file database, and then aggregate, slice, and dice this data, generating a number of useful HTML reports that illuminate trends in code quality, point out poorly written components, and highlight areas for improvement. Armed with this information, architects can make better decisions regarding process, policy, and design. http://www.bennorthrop.com/Home/Blog/2007_11_17_prisoners_dilemma.php http://www.bennorthrop.com/Home/Blog/2007_11_17_prisoners_dilemma.php Tue, 11 Nov 2007 17:25:12 GMT Imagine this... You and five other developers have just been hired as contractors for a 4 month project at Acme Corporation. Congratulations! Going in, you've been told that there's a chance some of you could be hired at the end of these 4 months to continue working on the system, and since you all prefer the stability of full time work, you're encouraged by this. You also learn that for Acme, releasing the software in 120-days is absolutely critical, and accordingly, your manager (who, incidentally determines whether you stay or go at the end of the contract) is most concerned with whether the system works, not how you make it work. Finally, you've all been given different functional areas to work on, so you'll be working relatively independently of your fellow contractors. Sound good? Now here's my question for you: will you comment your code? Deep down, you know writing comments is a good thing to do, but if the situation is as I described it, I'm guessing you might not. Here's why: