Tag: development

Winnowing the MoodleNet project down to MVP size

Note: this post refers to the MoodleNet project that I’m leading. More on that can be found here: moodle.com/moodlenet

Context

As a knowledge worker, you can’t win. If you do your job well, then the outputs you produce are simple and easy to understand. It’s your job to deal with complexity and unhelpful ambiguity so that what’s left can comprehended and digested.

In a way, it’s very much like the process of writing for an audience. We’ve all read someone’s stream-of-consciousness email that said much but conveyed little. Good writing, on the other hand, takes time, effort, and editing.

The problem is that high-quality knowledge work looks easy. Long hours of thinking, discussing, and experimenting are boiled down to their essentials. You just see the outputs.

Perhaps the most obvious example would be brand redesign: almost no matter what’s produced, the response is usually that the process resulted in money wasted. That’s even more true when there’s public money involved.

Belfast 2008

The City of Belfast spent around £200k on this logo in 2008. It’s a heart-shaped B conveying love. I quite like it..

As a result, logo designers tend to share the process which got to that point. They share iterations towards the final idea, any rejected ideas, and the conversations with people who had some input into the process.

Likewise, all knowledge workers should show their work, as Austin Kleon puts it.  This not only proves the value of the work being done, but invites commentary and constructive criticism at a time when it can be useful — before the final version is settled upon.

Process

A Minimum Viable Product, or MVP, is “a product with just enough features to satisfy early customers, and to provide feedback for future product development.” However, in my experience, there’s a few stages before that:

  1. Research: whoever’s in charge of the project (in this case, me!) situates themselves in the landscape, talks to lots of people and does a bunch of reading.
  2. Hypothesise: the same individual, or by this point potentially a small team, comes up with some hypotheses for the product being designed. A direction of travel is set, but at this stage it’s only as granular as north, south, east, or west.
  3. Design: a small team, including a designer and developer, take a week to ‘sprint’ towards something that can be mocked-up put in front of users. The result is the smallest possible thing that can be built and tested.
  4. Prototype: developers and designers come up with a working prototype that can be put in front of test users within a controlled environment. Sometimes this uses software like Framer, sometimes it’s custom development, and sometimes it’s powered by nothing more than Google Sheets.
  5. Build: the team creates something that can be tested with a subset of the wider (potential) user base. The focus is on testing a range of hypotheses that have been refined through the previous four processes.

Following this, of course, is a lot of iteration. It may be that the hypotheses were shown to be invalid, in which case it’s (quite literally) back to the drawing board.

Where we’re at with MoodleNet

Right now, I’m working with colleagues at Moodle around a job ‘landscape’ for a Technical Architect to join us in the next few months. In the meantime, we’re looking to work with a design and development consultancy to take us through steps 3-5.

It gets to the stage where you just need to build something and put it in front of people. They either find it useful and ‘get’ what problem you’re helping them solve, or they don’t.

You can’t be too wedded to your hypotheses. As project lead, I was sure that a federated approach based on an instance of Mastodon was the place to start, until I spoke with some people and did some thinking and realised that perhaps it wasn’t.

And, of course, it’s worth reminding myself that there’s currently the equivalent of 0.8 FTE on this project (I work four days per week for Moodle). Rome, as they say, wasn’t built in a day.


Image: HEAVENLY CROP by American Center Mumbai used under a  CC BY-ND license

Recontextualization.

To me, productivity is always productivity for something. I see no point in being productive simply for the sake of it. That’s because it’s all about outputs. The thing I love about working at JISC infoNet is that I’m ‘measured’ on what I produce, not how I go about doing it. In other words, I’m treated as a grown-up.
Read more →

Twitter is not the best CPD you’ve ever received.

I see this a lot:

  1. Someone is demoing Twitter.
  2. They ask their network why they use Twitter.
  3. People respond “it’s the best CPD I’ve ever received”

No. It’s. Not.

It might be the best Continual Professional Stimulation (CPS) you’ve ever received but development is more than getting a bunch of ideas. Development is:

[The] act of improving by expanding or enlarging or refining.

or

[A] process in which something passes by degrees to a different stage (especially a more advanced or mature stage).

That’s why TeachMeets, for example, are better CPD for those who present at them than for those who attend. Those who merely read tweets or attend TeachMeets are being professionally stimulated but not (necessarily) developed.

Happily, many of those who experience CPS end up undergoing CPD as they put those ideas into practice, reflect on it (via their blog, TeachMeet, etc.) and then make it better.

That’s development.

That’s CPD.

That’s all. 🙂

Image CC BY-NC TarikB

The problem with free stuff.

divieto?
Image: ‘divieto?

Background:

I like free stuff. I also like Open Source (OSS) stuff. I especially like FLOSS. OSS has a model that works:

In his 1997 essay The Cathedral and the Bazaar, open source evangelist Eric S. Raymond suggests a model for developing OSS known as the bazaar model. Raymond likens the development of software by traditional methodologies to building a cathedral, “carefully crafted by individual wizards or small bands of mages working in splendid isolation”. He suggests that all software should be developed using the bazaar style, which he described as “a great babbling bazaar of differing agendas and approaches.” (Wikipedia)

The trouble is, the only real ‘model’ that non-OSS developers have for making software freely available is freemium: making basic services free whilst charging for more advanced features.

The problem:

Educators get upset when services they’ve been using (for free) get shut down. That’s understandable.

Why are educators using these free, online tools? Because those that are provided for them don’t cut the mustard. Why aren’t they paying for the more advanced (premium) features? Because they would have to pay for them personally.

Solutions:

  1. Encourage/dictate that staff and students use only Open Source software (if a developer leaves, the software is still there and you can find/pay someone to develop it further)
  2. Give staff (and students?) a budget to spend on software/web apps (a bit like a personal version of the ill-fated eLearning Credits system in the UK)
  3. Have a backup plan (what other services could you migrate to if the worst came to the worst?)

Conclusion:

If you don’t pay for it (or, if ad-supported, click on the ads) don’t grumble if it’s not there tomorrow.

css.php