Development and UX from Michael Mahemoff. Maker of Player FM. Previously: Google, BT, O'Reilly author.

Menu

Tag Archives: Agile

The Problem

Much fun can be had designing with the ever-increasing universe of fonts offered by directory’s like Google’s. Photoshop Tamagotchi is a thing of the past as you can rapidly iterate with a few keystrokes. But it’s still a few keystrokes too many …

A niggle with CSS3 fonts is they involve some redundancy. Here’s a real-world example:

What happened to Don’t Repeat Yourself? We have “Delicious” mentioned five times here! If we switch from the “Delicious” font to the “Pinboard” font, we’ll need to make five changes. And not everyone uses vim, yo. Moreover, we’ll need to locate a suitable font, e.g. Pinboard, and download it.

I get it, this level of indirection serves a purpose. We can give a handle to the font once and then use that everywhere else. Heck, we could even continue to call the font “Delicious”, but surreptiously switch the “src” to “Pinboard-Roman.otf”. But that wouldn’t be very nice, would it?

Now, a font directory like Google solves part of the problem by explicitly allowing you to link cross-domain to Google. In fact, if you want, it will even generate the stylesheet for you. But you’ll still have the same DRY issue in your CSS – for each new font, you’ll need to include the stylesheet and use it in your CSS.

The Solution

Bottom line, I decided to make this crazy snippet, by manually walking through the font directory and picking out every single possible font:

Production Use

I haven’t tested it, but I’m informed modern browsers will thankfully download only the fonts they need, so this is actually a viable solution for sites which will be frequented only by modern browsers, though obviously the snippet itself is too big for sites where performance is critical.

Unfortunately, IE6-IE8 will actually download every single font specified! So really, you should only be using this for development, and ensure production sites only declare the fonts they need. However, don’t lose site of DRY! In the spirit of Agile, DRY, and Continuous Integration, it would still be worth looking at ways to automate that process, e.g. with a server-side solution that generates the minimalist “link” tag.

Of course, the snippet is limited only to the Google fonts, good enough for my aesthetically-challenged purposes, but the principle could be generalised to encompass other font directories. Or someone in a company which has licensed and/or issued a standard set of fonts via their style guide, could also generate a company-specific snippet fot this purpose, containing all fonts. They could then make this a standard stylesheet which could be linked to from any HTML document.

I’m at the inaugural Amped event, and you could immediately guess people were going to be using Node, from the fact they were breathing. So I pointed them to my , which is indeed a total hack.

Basically, you can do any multi-user app with a server of 10-20 lines. All you do is broadcast each user’s actions. In fact, such a server would make a great open source project (but I’m otherwise occupied playing with PhoneGap and Android). Sure, Node makes servers easier, but for version 0.01, this is all you need. A video sync app would get messages like this:

This is trading off security for productivity. There’s ZERO security here, because (at least the way I implemented the video sync) any user can forge a request from any other user. But that’s the point: It’s a hackathon. Unless you’re at a security hackathon, security doesn’t matter a hoot. Nor does maintability, readability, or most other -ilities.

If I was doing this for a “real” project, I’d start the same way. I’d be wasting my employer’s/client’s time if I was spending it if I did it any other way, since 9 projects out of 10 (</blatantly made-up stat>) never get out of feasibility phase.

(Update: How’s the timing? This blog post was written one day before Dion and Ben announced Bespin, the massively important open-source project to build an IDE in the cloud among many other things. Needless to say, Bespin has been added to the list!)

I would like to see more tools for UML tools to complement these online IDEs. I’m not talking about naieve enterprise silliness like model-driven architecture; I mean just some basic tools ot support basic sketching.

So here is a nice one Jeremy showed me: Web Sequence Diagrams. It’s based on a declarative text spec of the model, rather than endless, tedious, mouse clicking. A perfect example of the WYWSIWN (what you see is what you need) paradigm trumping WYSIWYG. Just a nice, simple, tool that lets you generate UML models in a matter of minutes, the most any agile practitioner would want to spend on them.

Share this:

Confirming that enterprise reuse can be a bit of a joke at times, Jason Gorman shares this fable on enterprise reuse (via another inspired Jason). Short summary: Two ladies could save 8 cents by boiling tea in the same kettle. But the cunning analyst forgets that, since they live 20 miles from each other, there will be overheads to the tune of a $20 cab ride and the travelling time.

Viewed from a high level, enterprise reuse is a noble goal; what’s the point of being a single company if everyone writes their own code? In practice, it can be fraught. Ironically, it’s usually easier to reuse publicly-available libraries (e.g. open-source libs on sourceforge) and public web services than those in the same company. The following things make reuse more digestible in an enterprise setting:

Language-agnostic, industry-standard, technologies Using obscure or proprietary technologies can work in an individual team, but rarely in a large enterprise; in most cases, there are simply too many factions with different skill sets and legacy code bases. There are companies that describe themselves as a “pure Java shop”, for example, but you will indefinitely find pockets working in Python, .Net, and so on. Getting an enterprise to truly standardise (not just lip service) on something non-industry-standard is futile. It takes several months for people to get really competent in a new language; in an environment full of contractors and staff turning over every few years, and full of legacy systems, you can count on the fact that there will be disparate technologies at play. It’s a good thing, too; no one language (or paradigm, for that matter), not even Java *gasp*, is the right solution to all problems.

Service-oriented SOA as in “built on a needs-driven basis”. The stuff that’s available for reuse is stuff that’s been abstracted from real-world projects, where at least one project already built it and at least one other project actually needs it. (Rails is successful because 37Signals uses it; there aren’t dozens of 24-month working groups involved.) Perhaps the biggest mistake enterprises make in this whole area is pushing out functionality no-one else actually wants to reuse.

Support trumps standardisation The best way IMO to encourage a certain technology or library is the carrot, not the stick. Make people actually want to reuse what you have to offer, rather than forcing them to do so. I am very sceptical about any situation where architects have to act as the reuse police; if the component or service was designed, documented, easily located, and served a genuine need, wouldn’t the developer be drawn towards it? Wouldn’t they actually want to use it, and maybe even give something back to it? In an ecosystem where components and services are high-quality and easily-accessed, you can forget about mandating reuse because it will happen anyway. See Web API Patterns and Documentation as Conversation for the kinds of things that will make this happen.

Online As a rule of thumb, offering a centralised web service is better than offering a reusable code component. The web service can (should) be easier to use and is language-agnostic. Obviously, there are sometimes situations where code components make more sense, especially from a performance perspective. I wouldn’t use an online service to create a polygon every millisecond, for example.

Easy to use As with any API, it should be easy to learn and make calls. For this reason, online services should be RESTful, not SOAP or CORBA or whatever MQ if you can help it.

Iterative progress Don’t try to bite off more than you can chew; if you start pretending *everything* can be reused, you’ll soon find that nothing gets reused.

Simple and parsimonious Factor out the trivial factors that relate only to one particular client. In enterprise reuse, this can be a big problem, where client projects may be the budget holder for anything reusable. It’s difficult, but someone needs to stand up and say “no, we’re not going to include feature X because no-one else would actually need it”. In software, deciding what to leave out is usually a greater challenge than coming up with new things to put in. Any feature that won’t be used by a significant proportion of client apps is going to create more clutter than its worth. In a broad-scale service, I’d say this minimum proportion should be something like 5-10% (e.g. Each method should be exercised by 5-10% of clients who used the class.) In an enterprise context, where there may only be a few clients, I’d say the criterion should be “at least 2 clients”. (There was a podcast interview a while ago, with PragDave I think, where he was asked what he would include in Rails 2.0. He essentially replied that he’s more worried about taking things out – push them out of the core distro and into plugins.)

Automated Sometimes, people think “it’s all under the same roof”, so getting access and learning about an API requires a call or a meeting with the owner of the reusable service/component. Whereas, if Google offers the same thing, it will provide online doco and a means of accessing it automatically, without any human intervention. An agile enterprise should aspire to do the same thing; it doesn’t have to be as polished as a public offering, but the spirit should be the same. Otherwise, it won’t scale, and the owner will soon become fed up doing the same thing over and over.

This podcast covers eight patterns on debugging/diagnosis of Ajax Apps, as well as testing Ajax apps, and I’m joined by Craig Shoemaker from Polymorphic Podcast, also a co-author of “Beginning Ajax with ASP.NET”. After some announcements, the interview begans at 6:00. The podcast overall is 60 minutes.

With the series now complete, the podcast will now resume regular Sotware As She’s Developed topics including but not limited to agile development, Ajax, the web, and usability. Also, more conversations – please drop me a line at [email protected] if you’d like to come drop in for a skype chat.

As always, credits on this podcast to My Morning Jacket for the lead-in track, â€œOne Big Holidayâ€. All podcasts in this series licensed under CC.

Audio Note: Sorry about the noise at some stages in this recording – I now know a lot more about audio levelling (the problem of keeping both ends at the same level), but at the time this was recording, it turned out I had set Craig’s end at too low a volume. I used Levelator to level each end, leading to too much noise…next time I’ll need to pump up the volume at each end from the start. I’m also looking forward to resuming use of Bias SoundSoap, but there’s no easy way to get this running on an Intel Mac for now!

Share this:

Dion posted a story about Nokia’s new mobile widgets. This will be very cool if it’s as good as it sounds. However, what got me was the XML-based config – three separate files for config, skin, and widgets. The widget config:

<!-- Configuration of servicehandlers which the widget needs to operate -->

<services>

<servicetype="syndication"id="feed1">

<referencefrom="feedurlrss"to="feedurl"/>

</service>

</services>

My comment here isn’t specifically about this project, because most APIs continue to use this convention. I don’t get why APIs continue to come out requiring complex EJB-style XML config, in three different files no less. Learn from Rails and Pico and use code for config.

The arguments for XML config are fundamentally flawed:

“Anyone can edit it, not just programmers”. And if you believe that, you’re still waiting for your manager to learn FORTRAN and COBOL, thus rendering programmers obsolete. Mwuhahah. Obselete, I’ll tells ya.

“It can be changed at runtime, no compilation required.” This might occasionally be useful if the app’s shipped off to another site, but that’s a slim minority – it will either be a hosted app which you can easily re-deploy after re-compiling (as with these widgets) or a desktop app which will hopefully offer a nice config UI rather than requiring the user to hack some XML files! We like to develop standards to serve the vast majority, not the slim minority.

“It’s neater.” In any modern language, you can easily develop an API that lets you perform configuration with a grammar resembling a domain-specific language. I don’t consider the above XML to be particularly neat, nor most EJB descriptors I’ve come across.

“It can be validated.” True, you can check the file’s grammar, but you can’t validate that a given attribute must be a class in your program, for instance. With code-based config, you can.

Share this:

How much doco happens on a project is one part opinion and one part “what do you want to optimise for?”. I generally find there’s a dichotomy in attitude to software documentation.

1. Definitive (aka normative, exhaustive, complete, bureaucratic, rigourous, formal). The ideal here is that everything should be covered in documentation – the docs are a snapshot of every activity, plan, and state of the project. The aim is: (a) to let you carry on unhindered if “(stakeholder/worker) is run over by a bus” for all instances of (stakeholder/worker); (b) affect payments and provide legal evidence/cover.
2. Informative (aka agile, pragmatic, informal, half-hearted). Use docs pragmatically, to help explore ideas, reach consensus, remember what we said, etc. You cannot reconstruct a project from docs like this – if everyone is “run over by a bus” at the same time, there will be a delay and a subsequent divergence in the project direction.

That’s a clear distinction – in the Informative mindset, the docs are only there to reach a better quality result; in the Definitive mindset, we’re compromising some productivity for the sake of risk management (both (a) at a tactical level, i.e. if someone leaves; and (b) at a strategic level, i.e. upper management can theoretically be comfortable about how much is exposed and how much they’ll get back as a penalty if things slow down, etc.).

Both Definitive and Informative have a range of approaches. In particular, Informative use of docs can range from none at all, up to a project resembling a Definitive project, but when you look closely, the docs are lightweight and only subject to informal reviews rather than full-on inspections and audits. They may also the use of less conventional “documentation”:

Whiteboards

Post-it notes

Flashcards

Wikis and blogs.

As an agile proponent, I’d generally favour the Informative approach, but software isn’t developed in a vacuum. Organisations understandably want to be reassured about what gets delivered, which pushes them to rely on Definitive methods. The problem here, of course, is that Definitive-style docs require an almost impossible task of pinning down requirements, and furthermore, fixing requirements runs counter to the modern organisation’s goal of being agile.

There’s obviously no one solution, but one essential ingredient comes from multi-talented people. Too often, requirements are penned by business people on the assumption that software developers are left playing with their compilers. That’s changed a lot over the past five years, and organisations will do well when they hire business people who have an interest and competency with software, and software developers (fast becoming the majority) who can empathise with the business’s needs and are actually literate as well.

(I hope it doesn’t go unnoticed that Software As She’s Developed has actually posted about software development. That’s so ’04.)

Cool! The Best Practices/Processes Patterns are now complete. They are the final eight Ajax Patterns for now – “final” in the sense of “the list is not yet finalised”. The patterns had been sitting there unattended for about four months now.

More details on the new patterns later, but here’s a quick summary …

First, there’s a new demo – the Ajax Patterns Reader – the best version to try is at http://ajaxify.com/run/reader/logging/realService/. The reader grabs the AjaxPatterns.org content and presents them Ajax-style. You actually queue up patterns in a playlist and click “Next” to “play” them. Yeah, a bit contrived, but it helped illustrate quite a few patterns! If I have time, I’d like to enhance it into a proper reader, and also offer an easy interface to leave feedback, which would be automatically appended to the wiki’s Discussion tab for that pattern.

Agile is a big theme these days. Not surprising that it should be a big part of “Web 2.0”, since Web 1.0 is often attributed as an inspiration. Paul Scrivens reminds us of [37Signals’ association with agile principles](http://9rules.com/whitespace/fear_is_a_good_thing.php] and that’s evident, for example, in this talk by Jason Fried. Similarly, the agile manifesto was mentioned in a Web Essentials talk last week (I think Kelly Goto’s talk, towards the end). And, of course, you’ll see “Agile” bandied around in most magazine ads run by consulting and IT companies, complete with obWhiteboardSketches.

What you don’t hear much of, in these bite-sized message, is how to do agile. I’m sure the speakers and their organisations know how (though I’m not sure about all the magazine advertisers), but how about the audience? I have visions of some people thinking, “1. Loosen up a bit. 2. ???. 3. Profit!!!!!!”. Hopefully, some of them will do some investigation and learn the how part, but for others, this has the potential to end in tears.

To clarify:

Agile is not just taking your tie off.

Agile is not just the manifesto.

Agile is not just whiteboards.

Agile is not just programming.

Agile is not just adding functionality.

Agile is not just setting up a wiki.

Agile is not just “we have to try harder”.

Agile is not just taking your tie off.

Here’s why:

“Agile is not just taking your tie off” because you need specific technologies, technical skills, and techniques.

Agile is not just the manifesto, because that’s a set of principles, not a manual.

“Agile is not just whiteboards” because no-one ever got paid for delivering a whiteboard. (With the obvious exception of whiteboard manufacturers, and it’s also likely some retailers in the corporate sector have made a tidy profit in the whiteboard market.)

“Agile is not just programming” because it’s also continuous design and testing.

“Agile is not just adding functionality” because it’s also refactoring existing functionality.

“Agile is not just setting up a wiki” because it’s the content that counts. (And in any event, use the wall instead of a wiki. Support your local whiteboard manufacturer today.)

“Agile is not just “we have to try harder” ” because that’s not sustainable, and even if it was, it’s not optimal.

“Agile is not just taking your tie off.” No, really. Keep it on if you like. It makes no difference. A black polo top doesn’t make you more agile.

(Vaguely inspired by hearing that Dave Weinberger’s going to be talking about what blogging’s not.)

What I like most about Extreme Programming is that it makes the practices explicit, whether you agree with them or not. “Refactor Mercilessly”, “You Ain’t Gonna Need It”, “Test-Driven Design” – they might sound like mindless mantras to the uninitiated, but they actually reflect a lot more concrete, rich, advice than “Chill Out”, “Loosen Up” and “This agile thing’s a breeze … (something about whiteboards) … profit!”.

Share this:

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff