Tag: design

Dreaming in Code

I’ve just recently purchased a new book, Dreaming in Code, by Scott Rosenberg.

It’s a good read, so far, but I’m only on page 100 or so, so I got a ways to go. Still, I’ve got to chime in right now because I’ve heard and/or read this before and I think it’s bullshit:

Here, once more, was the archetypal dilemma of software reuse. Build or borrow? Virtually every software project sooner or later arrives at this fork in the road. (The full phrase traditionally is “Build, buy, or borrow?” From a technical perspective, though, “buy” and “borrow” are similar, the commercial and open source sides of the same coin.)

Look, I don’t give a damn if you’re the most productive developer or architect in the universe, if you have a solution that fits your needs but perhaps only to 80% and you ain’t buying or borrowing, then you really shouldn’t be in charge of the project. Do yourself and your employer (or client, as the case may be) and focus on technology and let somebody do project management because you suck at it.

Bottom line is: write an interface. Then have the implementation of this interface be a simple adapter to some borrowed or purchased code. If you have time to make it better in the future, then plug in a new implementation. If you rewrite because you ain’t getting that last 20%, then you’re a fool. If you’re at this fork in the road, realize that you currently have 0%, and that you can probably crank out an adapter within a couple of days. 80% of the desired functionality within a few man/days. You have to be smoking something if you don’t follow that path!

Yes, I’m fairly extreme in my views on this, but I’ve found that I’m always right when it comes to this issue, too.

Note to Self: Use session token as argument across all your APIs.

If you’re gonna be running code on any kind of multithreaded environment, a service layer of any kind, whatever… In other words, unless you’re actually running on the GUI and you’re actually dealing with event-driven development… please please please add a session token as an argument to every method call in your API.

You probably will think: “Why? I don’t need it.” But if and when you do, it might be too late… because you might be live at several clients, and you may not be able to change the API at that point in time, or you have to be backward compatible, right? Well, if you ever plan on having two-phase commit, or horizontal access permissions, whatever… you better have some kind of session token that allows you to retrieve your “context.” If you don’t have that, you’ll hack it…. oooohhhh, you’ll hack it real good, because you won’t have a choice. But you know what? If you ever want a clean fix: you’re shit out of luck!

Ideas emerging from necessity

It’s funny how software comes to life…

I designed a reporting framework for Calypso. It is used to plug easily and extract data from the system. Among the many features, it’s possible to customize the way the data is displayed, whether to aggregate and on what fields, keeping subtotals, averages, and various other aggregation functions, and easily allows the data to be exported to HTML, Excel, and PDF. Simply put, you write 3 classes, one that defines your search criteria, the main class that takes this search criteria and “queries” the system via the API, and a class that extracts discrete column values from an object. You compile these classes, plug the name of the new report into a database table, and you’re good to go: You will get a GUI for this report and it will allow you to sort, aggregate, basically slice and dice your data every which way you like. You can export the data to all the aforementioned file formats…. It’s probably very similar to Crystal Reports and is definitely similar to Excel in that we’ve implemented some functionality based on what we found in there. The nice thing, though, is that because it’s built and tailor-made to plug into the API, it provides a nice level of abstraction. I can typically crank out a brand new vanilla report in half a day. No kidding.

The report framework is only about a year and a half old and I pretty much worked on it solo for the first 9 months. Now we have probably 5 to 6 developers using it, making enhancements, refactoring the code, what not. It’s been integrated into a variety of GUI windows and we have over 60 different reports built on top of this framework. What’s really interesting though is its reason for existing. Did we brainstorm and decide we needed to offer this functionality, both for use internally and for our clients? (Several clients are loving it, by the way, and are already building upon this framework extensively.)

Nope.

The reporting framework was born out of sheer desperation as I was assigned 15 back office reports to implement from scratch with a delivery 2 weeks later. Well, actually the delivery was 4 weeks later, but this enhancement request for a very large New York-based bank came into my mailbox exactly 11 days before I was to head off to Tuscany for a wedding.

“Let me get this straight,” I thought, “They want 15 brand new reports, with GUI and the ability to run on a scheduled basis?” I did the quick math… “That’s a minimum of 75 new classes that I need to write and debug if I am to deliver all these reports and follow the existing design guidelines to implement reports.” Not completing the reports was not an option. It had been negotiated from above, and I certainly sympathize with a client that’s paid a lot of money for a very good SLA. But we’re talking Tuscany here… Sienna, Firenze, and Brunello. Not going to Italy was not an option!

So I figured my best bet was to build upon the existing interface-less report methodology, refactor the code extensively, and make these new reports “pluggable” into a generic GUI window. Next thing you know, the reporting framework was born.

I’m just thinking back on this as I am currently drafting a developer’s guide on the subject. Since that beautiful September day when I began coding it, the reporting framework has grown at mindblowing speeds. It can be updated real-time by plugging into our event server. Search criteria can be exported to XML and be shared across multiple users. Clients can extend the framework and build their own custom aggregation functions. We provide sums, averages, minimums, and maximum functions out of the box. All kinds of tweaks can be made to the look of the output as views can be customized with row and column color settings based on whether such condition is met.

It’s a trip to see the organic growth of this framework even with just a handful of developers having access to the source code… Have a great weekend.

Peace.