Whew… it’s been, like, what… half a month since I last updated? Way crazy busy, but there’s been a lot to talk about. Here’s a quick roundup:
As you may (or may not) recall, I spent about three weeks in PeopleSoft training. At the time, I totally drank the Kool-Aid and found my initial concerns about the platform fading. Now that I’ve had my hands in it, I feel the fires of my frustration renewed. I’ve already ranted on my issues with PeopleSost’s insistence on using archaic and proprietary languages (SQR? PeopleCode? Perl! Python! ECMAScript! Jeez…) but I’m also frustrated with the user interface. There’s no simple way to document expanded functionality, and their PeopleBooks documentation is arcane and error prone. All in all, I find the whole situation very frustrating.
As a developer, I want to be right up next to the computer. I hate having too many levels of abstraction between me and the system. PeopleSoft is a platform on top of a platform on top of a platform, and each additional level adds complexity that is almost unnecessary. An open source enterprise system to replace/complement PeopleSoft, SAP and Oracle would be very welcome. If nothing else, it may spur some further innovation from these existing sleeping dragons, forcing them to think more in terms of flexibility for the customer rather than locking them in on their technology.
Emerging Technology Conference
Last week in Santa Clara, O’Reilly hosted the Emerging Technology Conference. Working in San Francisco for a decidedly non-technical company (hello… ART COLLEGE?), there was no way that I was able to make it down. Which is a genuine shame as there were TONS of great topics being discussed that I would have dug. But what is a conference about cutting-edge systems that doesn’t actually try to prove the technologies being discussed? It turns out that physically going to the conference, while optimal, was not necessarily the only way to attend the conference.
The organizers hooked up with Socialtext to produce the ETech Wiki. A wiki, for those not in the know, is a type of website where the community can freely add, edit and delete pages to create something of a free-form informational hub. You really have to see it to believe it. They’ve been making the rounds and gaining a bit of publicity in the geek press for a while now, but it always sounded way too chaotic for my taste. When the height of Internet cracking is the defacement of public websites, a wiki just seems to make it all too easy for the assholes of the world to let their presence be known.
The ETech wiki was my first foray into this little spot of technology and, despite a few problems, it turned out to be wildly effective. Most of the folks attending the conference were connected to the Internet via the WiFi (802.11) networks provided at the conference. This meant that they could bring their laptops, PDAs or what have you into the conference and stay connected, discussing the sessions in chatrooms and through instant messaging while immediately posting the notes they took online.
SciFi author Cory Doctorow‘s notes from Bunnie Huang’s talk on hardware hacking fascinated me. While I’m sure they lacked in some of the detail that Bunnie covered, they were detailed enough to give me the feeling of having been there. The notes were unpolished, riddled with typos and incomplete sentences and were short on descriptive images and illustrations, unlike an edited, professionally written article covering the event. But that’s part of the point. It was a completely unvarnished account of what took place, like looking at a reporter’s notebook instead of reading the article. Anyone who has done a little journalism knows how much needs to be left out of the finished story in order to meet deadline and fit into the space granted them by the editors. A lot of interpretation must occur during that translation from notes to story, and much of what is initially written down isn’t really suitable for consumption by the reader who prefers to passively read rather than try to connect the scattered notes of the author. But, when it comes to tech how-to’s and the like, those scattered notes are often extremely useful as the author, in the translation phase, may have misinterpreted something or overlooked a vital piece of info that simply didn’t fit into the time and space granted them.
Of course, the beauty of posting these notes in the wiki means that someone else who attended that session can come in, take a look at what Doctorow wrote and fix any errors or add any extra notes they feel is missing, and all without having to go through the hassle of contacting the author, asking for permission, and, perhaps, never getting a response. It happens on the fly. I myself fixed a couple of Doctorow’s typos, just to see how the system worked. I’m flabbergasted. It requires a writer to give up some of their ego to allow this happen — even more so than allowing an editor to rip through their prose — but, if they remember that they’re writing for an audience that will going to try to actually use what they have written, it will end up benefiting the reader rather than hurting them.
The wiki wasn’t the only impressive thing to come out of the conference. Ideas like Smart Mobs (which got a lot of press despite the fact that Harold Rheingold changed his speech topic at the last minute) and swarm intelligence — as well as warnings about how such groups can be their own worst enemies — were enormously inspiring. So much so that I’m working on implementing one or two of them myself as we speak. (You wanna know more? You’re gonna hafta ask me.) And then there was Tim O’Reilly’s talk on what’s on his radar. (Essentially, technologies that encourage geek communities to contribute to their development). I could wax on all day about this, but it’s best you check it all out yourself. I found the whole conference amazingly inspiring.
One ETech inspiration was using a wiki for collaborative developer documentation. I find that, as I work on a project, I think of things that I will later need to add to my final docs for the users so that they are aware of certain features and limitations. I usually jot these down on a note pad somewhere. All too often, those notes get buried amongst the other scribblings I jot down as I work and can get left out of the final documents.
The idea of having an easily editable/updateable area for my development docs was very appealing to me. As I work, I can write down the warning to the end-user in a place where they can immediately see them and determine whether that’s acceptable. I can watch my documentation grow as I proceed on the project, adding here and there as more functionality is added. Once I have delivered the project, I can go back and clean up my notes rather than transcribing them from pad to computer. As the user gains experience with the product and finds errors — and workarounds — or undocumented features, they can easily add these to the official documentation themselves. QA teams can do the same. The wiki is a truly living, breathing document.
At the Academy, we don’t have a QA team. Nor do we have tech writers. Though we do a lot of our own development, it always gets tested and documented by the developers themselves. This is a far less than ideal situation. A wiki would ease this by allowing the free flow of ideas and notes to take place throughout the lifecycle of a project. To test my theory, I have implemented a wiki using PHPWiki running on Apache with a MySQL backend on my workstation. So far, I’m the only user (I have yet to even announce its existence to the rest of the team – there are still some bugs to work out) but I’ve found it remarkably useful. I have fully documented three current projects in about a quarter of the time it usually takes. I leave a browser pointing to the wiki open on my desktop at all times so that it’s a simple matter of alt-tabbing over.
Of course, it’s completely useless if no one uses it, and I’m afraid that’s what I’ll be up against once I release this to the rest of my team. This is not a true tech shop, and it seems that many of the folks here have limited experience in a true development-for-production environment. The concept of the software development cycle is almost completely lost here and asking them to document their work like this, despite being easier than actually producing traditional documentation, is essentially asking them to do more work as no one currently requires them to document their projects. The complete lack of documentation here is, in fact, what prompted me to give this a shot.
I’m growing tired of asking everyone for information about our systems, only to be turned to someone else who still doesn’t have an answer. I literally go in circles like this every day. Simple documentation – even just the slap-dash publication of developer notes – would help the situation immensely. And, rather than suggest it to someone who may get excited about it but quickly drop it when another big project comes down the pike (VERY short attention spans here), I chose to implement it myself, get it working and THEN announce its existence. It’s not keeping me from getting my other projects done (I’ve been staying late to work on it a little each night) so no one can complain that it takes the focus from something else. It’s kind of sad that I need to do that, but that’s part of the problem in working for a company where technology isn’t the focus.
If I can build an internal community around a wiki, I think we’ll see improved efficiency and communication. Little things like this can make a huge, positive difference to a strong team.
Lazy Americans (please pass the Cup O’ Soup)
Read this in the Food section of the Chronicle this morning:
“A comprehensive study of American food trends, published in the Institute of Food Technologies magazine in April, shows that more consumers are interested in trying a anew low-carb product that a low-fat one. Low-carb was fifth on a list of what consumers most wanted in new food products, behind ready-to-eat, heat-and-eat, eat-on-the-run, and foods that required no utensils.” (emphasis mine)
This leads me to my latest get-rich-quick scheme: Vein Vittles! Why waste your time heating and chewing your food when you can get those nutrients straight into your blood stream? Eat on the go! Great for the kids! Also comes in a low-carb version for you Atkins acolytes! (60% CriscoTM.)