Software engineering best practices, theory, horror stories, etc.
Recent Comments
- james edwin gage on At The Risk of Stating the Obvious
Category Archives: Software Engineering
Software Engineering
Reactions to NeoVictorian Computing
November 10, 2007 – 3:30 am
One of my inspirations as a professional is a man named Kelly Mehler, the father of a childhood friend of mine, who runs a small furniture-making shop and teaches woodworking. He’s eschewed mass production and has made a successful and profitable career out of hand-making furniture that is beautiful both in its visual appeal and its utility. Though he certainly can’t produce furniture as cheaply as a large operation in a lower-wage country, his business model is under no threat from such competition. And he can be proud of his work every day. These are things I’d love to be able to say about my own career.
So, it’s with that context that I stumbled upon Mark Bernstein’s recent posts exhorting a NeoVictorian movement in computing. (No, I wasn’t searching for cosplay photos.) Suffice it to say that I’m sympathetic to his central thesis that the rhetoric and practice of computing in “the enterprise” can be alienating for the practitioner and detrimental to the practitioner’s creativity. Writing software within a large corporation is not always subject to the criticisms that Bernstein makes, but the risk is there.
For many software engineers the solution is to participate in open-source projects which allow them to work on ideas that their dayjob doesn’t give them a chance to do. For others, the solution is to take a run at a startup idea of their own. And then there’s Bernstein’s approach, suggesting that perhaps the whole target of enterprise computing is flawed. I think that he’s right to suggest that there exists a whole class of software that might be built for the individual knowledge worker, and which offers ISV’s the opportunity to exercise their creativity.
However, it’s clear also that the core of enterprise computing will always offer a lot of unique engineering challenges and pay a lot of software engineers’ salaries. I think that, at a minimum, working in that environment successfully requires:
- actually caring about the business/industry in which you’re working
- being part of a talented, collegial and motivated team
- knowing what you want to work on and being direct about it
- being agile (small ‘a’) enough to not get too rattled by the fickle nature of business requirements
- having the guts to speak up (diplomatically) when you think an idea is just completely wrongheaded
Clearly, some of those attributes are social rather than being strictly technical. And some of them are attributes of the organization itself. So we as software engineers need to pick our employers carefully, and recognize that that we need social skills as well as technical ones.
SourceForge: Hot or Not?
October 23, 2007 – 2:27 am
Wonderful, now that I’ve set my little code project up on SourceForge, Tim Bray comes along and bursts my bubble. The consensus among his commenters seems to be that Google Code is the better place to put your projects. All that work going through SourceForge’s FAQs and help documentation just to discover that I’ve lost cool points! Ah well, the most labor intensive part of getting set up actually had nothing to do with hosted source control — namely, reorganizing the project to use Maven. I think if I need to move the project it will be easy enough to do so, although SourceForge does have some draconian rules about never removing files that have been posted. In any case, I will give Google Code a closer look in the near future.
Quick impressions of WADL and REST services
October 10, 2007 – 1:54 am
When I came across the WADL spec 6 months or so ago, it seemed to me that it was reaching for desirable goals. I’ve done a number of integration projects using SOAP, a few involving more ad-hoc XML-over-HTTP designs, and even a couple recently that more consciously strive to be REST-ful. Through those experiences, one of the things that I have liked about SOAP is that one can exchange a WSDL file with another organization and get server-to-server integrations moving along pretty quickly. Furthermore, if you’re used to reading WSDLs and the author wrote it sensibly, you can get a precise understanding of what data is going on the wire, and generally what’s involved in using a service in a shorter time than poring through prose documentation. Maybe it’s some form of software Stockholm Syndrome, but I’ve grown to like the ol’ WSDL. The larger WS-* family of hydra-headed standards gives me the same headaches that it gives others, but I do think that it’s nice to be able to hand over a machine-processable description of your system’s API interface which enables remote clients implemented in nearly any programming language on any OS to access its functionality.
So on the basis of recently re-reading the WADL spec and writing a couple of test WADL documents, I’m pretty confident in saying that WADL has at least achieved the basic goal of applying the WSDL concept to the REST service world. On top of that, the spec is lucid, succinct and highly readable — it’s like poetry compared to any of the WS-* specs.
There is a fair amount of criticism of the WADL effort from the RESTafarian camp, but none of it actually takes the spec to task for being poorly done. Rather, the criticism seems to center around the idea that the whole notion of a formal description language for REST applications is misguided from inception. Some of the highlights of that criticism come from Aristotle Pagaltzis, Mark Baker and Dare Obasanjo.
I think Aristotle’s remarks are perhaps the most valid — maybe a different sort of specification (along the lines of the ATOM Pub. spec) is needed to go whole-hog with the REST approach. But on the other hand, I’m willing to bet that 95% of the people who turn their nose up at using something like WADL will then turn around and write their plain old human readable documentation in such a way that it describes exactly the same things that WADL describes: what URLs to hit, what parameters to pass, what data to expect in return, etc. Because so far that’s what I’ve seen in APIs such as the ones offered by Flickr, Facebook, etc. To my mind, having a succinct, easily machine-processable form of documentation for your code seems like a win.
Engineering Parenthood
July 24, 2007 – 5:09 am
Parenthood and software engineering share at least a couple of similarities. Most software engineers can relate to the experience of a project that seemingly has no end, with problems for which you cannot see the solution at the outset but which you nevertheless must solve. But when you are a new parent it is suddenly like you have two jobs with twice the demands. You cannot shortchange your child with regards to time, effort or inspiration and neither can you simply phone it in at work. Putting in the minimum effort is not why anyone sane gets into the business of writing software — we want to produce high-tech, shiny, cutting edge, cool stuff.
So therein lies the challenge: how does one keep the edges sharp when you’re sleep-deprived, juggling seriously conflicting priorities and pressed for time on all sides? I’m facing this situation now, but I don’t have an easy answer. I can only offer my guesses.
Time Management
One part of the solution is obviously time management. Maybe your time management practices are already ninja-level, but I’ve found that I need to tighten up my time management practices as much as possible, because I can no longer rely on burning the midnight oil to get me through difficult spots. That means automating as much as can be automated. It means allocating small, scheduled windows for distractions like reading random tech news on the Internet. It also means really prioritizing work and banging tasks out like a waiter in a restaurant — knowing what can be kept waiting briefly and what must be done NOW. There are all sorts of time management philosophies one can follow and tools you can use, but probably the most important thing to do is pick some method that works for you, and use it.
Cooperation
Improving your time management practices should help with handling the current set of tasks, but holding a line in the sand is never good enough with software. You must stay on top of emerging technologies, improve your skill set, experiment with different techniques, etc. In software engineering, as in many endeavors, to stand still is to become a fossil. Naturally, having a child puts your woodshedding discipline to a serious test.
If you’re lucky, the child will be a consistent sleeper and you can sneak in an hour here or there at night to get things done. You should exploit those opportunities when you can, but ultimately, you’re going to need the cooperation of your partner to make sure that you can get a chunk of time on some sort of semi-regular basis to do your extra-curricular coding. Undoubtedly you’ll need to reciprocate in kind. It is well worth it to work something out, because though one can get some things done in fits and starts, there’s no substitute for a several hour chunk of time when it comes to writing software and you’re not going to get that time without help.
Elbow Grease
The third point that I think is important is: have an extra-curricular project to work on. The main reason for this is that you need some focal point for your woodshedding efforts. You WILL have weeks when you get nothing done, when you have to put aside any extracurricular learning and development, and having a project will help you pick up the pieces when you regain some time. After all, you are a finisher by nature and you don’t like to leave projects undone (right?), so your instincts in that regard should help you follow through.
The project might revolve around some new technology you’re interested in, or a new problem domain you want to explore, or just an itch (a la Eric Raymond) that you need to scratch. Taking some training course that you can get your employer to foot the bill for is not a bad idea either. Pick something very manageable, because inevitably it will become a bigger deal than you think, and what you need now is a confidence builder, not a Herculean challenge.
The Blind Leading the Blind
So there you have it, those are my “secrets” to success. Quite obviously I’m new at this game. Perhaps I am naive and overly optimistic to think that I or anyone else can keep up the pace, but as the saying goes, shoot for the moon and maybe you’ll end up on a cloud.
About