Doomed To Reinvent

There's an old saying, “Whoever doesn't understand X is doomed to reinvent it.”X can stand for any number of things. The other day, I was pointing out that such is the case for ORM developers. Take ActiveRecord, for example. As I demonstrated in a 2007 Presentation, because ActiveRecord doesn't support simple things like aggregates or querying against functions or changing how objects are identified, you have to fall back on using its find_by_sql() method to actually run the SQL, or using fuck typing to force ActiveRecord to do what you want. There are only two ways to get around this: Abandon the ORM and just use SQL, or keep improving the ORM until it has, in effect, reinvented SQL. Which would you choose?

I was thinking about this as I was hacking on a Drupal installation for a client. The design spec called for the comment form to be styled in a very specific way, with image submit buttons. Drupal has this baroque interface for building forms: essentially an array of arrays. Each element of the array is a form element, unless it's markup. Or something. I can't really make heads or tails of it. What's important is that there are a limited number of form elements you can create, and as of Drupal 5, image isn't fucking one of them!.

Now, as a software developer, I can understand this. I sometimes overlook a feature when implementing some code. But the trouble is: why have some bizarre data structure to representa subset of HTML when you have something that already works: it's called HTML. Drupal, it seems, is doomed to reinvent HTML.

So just as I have often had to use find_by_sql() as the fallback to get ActiveRecord to fetch the data I want, as opposed to what it thinks I want, I had to fallback on the Drupal form data structure's ability to accept embedded HTML like so:

$form['submit_stuff'] = array(
  '#weight' => 20,
  '#type'   => 'markup',
  '#value'  => '<div class="form-submits">'
             . '<label></label><p class="message">(Maximum 3000 characters)</p>'
             . '<div class="btns">'
             . '<input type="image" value="Preview comment" name="op" src="preview.png" />'
             . '<img width="1" height="23" src="divider.png" />'
             . '<input type="image" value="Post comment" name="op" src="post.png" />'
             . '</div></div>',

Dear god, why? I understand that you can create images using an array in Drupal 6, but I fail to understand why it was ever a problem. Just give me a templating environment where I can write the fucking HTML myself. Actually, Drupal already has one, it's called PHP!. Please don't make me deal with this weird hierarchy of arrrays, it's just a bad reimplementation of a subset of HTML.

I expect that there actually is some way to get what I want, even in Drupal 5, as I'm doing some templating for comments and pages and whatnot. But that should be the default IMHO. The weird combining of code and markup into this hydra-headed data structure (and don't even get me started on the need for the #weight key to get things where I want them) is just so unnecessary.

In short, if it ain't broke, don't reinvent it!


Fuck Typing

chromatic's post on Perl Roles reminded me that I've wanted for some time to blog about another kind of composition. I call it “fuck typing.” It's kind of like duck typing, only not really. I would explain, but I think that my good friend, Mr. Vinnie Goombatz, will do a much better job. Although if you're squeamish or easily offended, you might want to skip it.

How you doin'? Theory aksed me to talk about fuck typing. It'd be my fuckin' pleasure.

You know how sometimes you're hacking (I love that word, “hacking”) some piece-a shit code, and you're using some cacasenno's module, but it doesn't quite do what you fuckin' want it to do?

Here's what you say, you say, “Oh, you don't fuckin' want to gimme a fuckin' prosciutto method? You got a fuckin' problem? 'Cause you're about to have a fuckin' problem, know what I'm sayin'?”

I tellya what ya gonna do. You gonna fuckin' open up that fuckin' paisano's module, right there, just fuckin' cut it right open, and then you gonna fuckin' shove the a prosciutto method right into the module's fuckin' guts. “How do you like them apples, you fuckin' piece of shit?”

And that's what you do. You fuckin' show him who's boss, know what I'm sayin'? If you don't get the fuckin' interface you need, you fuck the module up until you get it. Ain't no big fuckin' deal. Nice doin' biznizz wit'chou.

What's surprising to me is how accepted this sort of bad behavior is in some communities. Oh, well, there are all kinds, I guess.

Software Development Methodology

I feel that it's important to have a comprehensive approach to software development. It's not enough to be good at coding, or testing, or writing documentation. It's far better to excel at managing every step of the development process in order to ensure the quality and consistency of the end-to-end work as well as of the final product. I aim to do just that in my work. Here I briefly outline my methodology for acheiving that aim.

First, good software development starts with good planning and research. I strive to attain a thorough understanding of what I'm developing by listening to the people to whom it matters most: the users. By gaining insight into how people in the target market think about the problem space, and by strategizing about how technology can address that space, a picture of the product takes shape. This research coalesces into a set of pragmatic requirements and goals that balance the demands of a realistic development schedule with the needs and desires of the target market.

Once the requirements have been identified, it's time for prototyping. Task flow diagrams of user interactions model the entire system. Evaluations from the target market refine these schematics, shaping the look and feel of the final product. I cannot emphasize enough the importance of seeking market feedback to build solid and meaningful metaphors into the design. These concepts drive the user experience and make or break the success of the final product. The outcome of this feedback loop will be a UI, terminology, and object design grounded on intuitive concepts, scalable technologies, and a reliable architecture.

Next, a talented development team must be assembled and backed by a dependable, project management-oriented implementation infrastructure. Team-building is crucial for the success of any product, and in software development, a diverse set of engineers and specialists with complementary talents must come together and work as an efficient whole. As a result, I consider it extremely important to create a working culture of which team members want to be a part. Such an environment doesn't foster a sense of entitlement, but rather of conviviality and excitement. If team members believe in what they're doing, and they enjoy doing it, then they're likely to do it well.

And what they'll do is actually create the software. Each element of the product design must be broken down into its basic parts, fit into a generalizable design, and built back up into meaningful objects. I further require detailed documentation of every interface and implementation, as well as thorough unit testing. In fact, the tests are often written before the interfaces are written, ensuring that they will work as expected throughout the remainder of the development process. All aspects of the application must be implemented according to a scalable, maintainable methodology that emphasizes consistency, quality, and efficiency.

The emphasis on quality naturally continues into the quality assurance phase of the development process. The feature set is locked so that development engineers can work closely with QA engineers to test edge conditions, identify bugs, fix them, and ensure that they remain fixed. I prefer to have QA engineers punish nightly builds with suites of tests while development engineers fix the problems identified by previous days' tests. QA is considered complete when the product passes all the tests we can dream up.

And finally, once all of the QA issues have been addressed, the final product is delivered. Naturally, the process doesn't stop there, but starts over -- in fact, it likely has already started over. New features must be schematically tested with likely users, and new interfaces designed to implement them. The idea is to end up with a solid product that can grow with the needs of the target market.