Loosely Coupled

I haven't had a lot to write about this month. I'm in the middle of this seemingly endless, painful cycle where the more we regression test, the more unimplemented requirements we uncover. That's right, regression testing is defining our requirement set . It's a symptom of this big rewrite I'm working on. The system has been around so long, that no one can remember every intricacy in the existing application. Regression testing is the only way to uncover the missing functionality. It's a nightmare! Compounding the problem is the difficulty in regression testing. There is a "certification" environment that is supposed to be an exact replica of production. But when we try to run production requests through our new application, the results are different. Our business users review these inconsistencies and often tell us that our responses are actually better than the production version. This is a good news/bad news type of thing. While it's...

I just listened to Kent Beck's presentation from this year's RailsConf for the second time (something I almost never do). One of the gems I loved about his presentation was when he described test driven development as "cheating" (at the 27:08 mark). Exactly! I feel a little foolish for not thinking about it about this way before. It is cheating! How many times in school did I wish I had the answers to tests before I took them? Or wished I even knew the questions? Answer: Every time. Why? Because it would've been so easy! Imagine all the time I would've saved, with assurance that my work would always be correct and complete. Extending this idea to software development should be a no brainer - figure out what the software should do ahead of time (and write tests for it). This way you know exactly what to code, when you are done, and that your solution is complete and correct. It's so easy (it feels like cheating).

I'm usually not in charge of scheduling. I've contributed to schedules, but someone else - usually someone from management - drives schedule creation. I also can't remember a situation where the schedule actually worked. What I mean by this is, a lot of time was spent to create schedules for 2-3 months into the future - then not really revisited (adjusted) for a month or more. By this time something invariably happens (priorities change, initial tasks take longer than expected, vacations/time off weren't accounted for, etc.). This throws the entire thing out of whack and quickly makes it obsolete. A month or more will pass, then the whole process starts again with the creation of another schedule. For the project I'm currently on we've spent a lot of time creating 2 schedules from scratch and are currently creating a third. The first two have been complete failures and I have low expectations for the third. It's frustrating to spend a lot of time and ...

Steve Yegge has this great post today about business requirements and building software that you'd personally use in a domain that you actually know . Great stuff! I need to figure out a way to print wallet size copies to hand out at requirement meetings.

When I first joined this SOA team, I questioned the architecture we were implementing. The application flow is basically linear and uses JMS to pass messages between the various functional components. The components themselves were not designed generic enough to be shared by multiple applications. Like I mentioned earlier , the main driver for rewriting this application was for speed. The whole thing seemed very unSOA-like to me. Since none of the components were reusable outside this application, why not code the entire project in a "traditional" way? This approach would improve performance, replacing the overhead of multiple marshal/unmarshal operations needed for JMS with direct function calls. My perspective changed (a little) recently when we needed to add new functionality to the system. We could have modified one of the existing components to implement the new feature. Functionally, it made sense to keep this related logic together in a single module. The main p...

When developing Java RPC-style web services, I'm torn whether to follow a top-down or bottom-up approach. Using the bottom-up approach, you create your Java classes first and use the @ WebService and @ WebMethod annotations to specify that this is your web service interface. The WSDL for the service is generated automatically during the build (pretty nice). This approach has it's advantages in that you never have to leave Java to create the WSDL. Creating a WSDL file is not trivial and using this approach means you never need to think about the WSDL's <service> , <binding> , or <portType> elements and how they're linked together. Conversely, a top-down approach means you create your WSDL first, then use a utility (either your IDE or a command line program) to generate the Java skeleton. Using this approach you need modify the generated Java stubs to call your business logic. If the interface (the WSDL) changes, you'll need to regenerate t...

I've started to use JCAPS 6 a little of over the past month and thought I'd share some of my initial impressions. Finally a JCAPS editor I can use! I found the previous version of the JCAPS IDE hard to develop with. It was based on Netbeans 3 and didn't have a lot of the features I had grown accustomed to using ( refactoring tools and a local history to name two). It was just plain old, clunky, and slow. The new version is based on the latest Netbeans and all the goodness is back. And it's fast. No more repository. Well, almost. JCAPS 6 has a few different modes to work in - repository based or non-repository. A repository based project allows JCAPS developers to work in essentially the same way they did with JCAPS 5 - JCDs , OTDs , connectivity maps, deployment profiles and yes - the repository. It's also the way to migrate legacy JCAPS project to the new platform - through a simple export and import between the repositories. I haven't used t...