Changes at Hedtek

After seven productive and enjoyable years we’ve shut down the previous incarnation of Hedtek in favour of avenues new. We no longer perform bespoke development work. Instead we are pursuing opportunities around a product we spent the last four years developing.

However, we still do some external work, if you need a consultant or contractor, please contact us.

Some of the areas we are interested in working in are:

  • Interim CTO services
  • Project management
  • Product ownership/management
  • Rapid requirements analysis
  • User interface design and evaluation
  • Software engineering method review and coaching, including for agile approaches
  • Mentoring startups, particularly in respect of development of early stage systems
  • IT strategy


Contact Details

mark @
+44 | 0 7830 212 464

Posted in Uncategorized | Leave a comment

A guide to commissioning software part 2: Questions about agile practices

In part 1 I covered a few of the advantages of agile development when commissioning software. In this second post, I deal with common questions that arise from a client perspective; particularly for clients who are new to working with agile developers.

I start with a couple of big questions, about money and particularly about value for money and procurement, and them move on to questions about working with agile developers; what to do to maximise productivity and maximise the probability that the delivered system delivers business value.

This is a developing blog post, asking questions in the comments or mailing them in (mark at hedtek dot com) will result in more questions and answers being added here.

Do agile developments deliver value for money?

Agile developers don’t charged fixed prices. Instead they charge according to labour expended on the project. In such circumstances it’s natural for clients to wonder about value for money, and if the software cost is going to spiral out of control.

An experienced development team should be able to give you a ‘feels like’ estimate of costs on the basis of time involved in developing similar solutions. The cost of developing radically new systems can’t be estimated in this way; often a ‘suck it and see’ approach of doing some work and using experience so gained helps markedly refine expenditure estimates.

Agile solutions are likely to be more cost-effective than conventional solutions, for these reasons:

  • Agile delivers the solution you want, rather than one you think you want before development starts.
  • The process avoids big up-front specification, which is always a source of problems and instead uses more effective and tractable specification methods during the project.
  • The process can incrementally deliver early releases which provide the most important business value ready for use.
  • For various technical reasons, agile development is more efficient than conventional development.
  • Agile can deliver more robust, reliable and maintainable code
  • Expenditure avoids the often very considerable ‘safety margin’ that is built into fixed price contracts .

But my procurement process can only deal with fixed prices!

Simple, get the agile company to bill regularly against a fixed sum. If the project finishes before all the money is spent all the better.

When does an agile project end?

In most forms of contracting used for agile development, there is considerable flexibility about what goes into the project, you can stop the process when you have enough business value realised in the new system.

Often this goes hand-in-hand with in-project the discovery that you don’t need some features you thought were compelling, and would have paid for in a conventional project.

Co-operative work and communications between clients and developers – what does that mean for me the client?

There is a wide variety of communications patterns between clients and developers, for agile development processes to work there needs to be a minimum level of client involvement: You need to work with the developers to specify, in an incremental way, what you want from the system.

In turn the developers should be showing you the system on a regular basis; perhaps every two weeks. Good developers will have a development server on the Web, which means you can go there and look at progress whenever you want to.

This is not recommended, but: Sometimes it may be possible for you to minimise your involvement in the project, if the project team has a surrogate product owner (or product manager) who understands your application domain and can make decisions on your behalf. But in cases like this, if the team delivers something you don’t want, you have only yourself to blame!

Posted in Uncategorized | Leave a comment

A guide to commissioning software part 1: The advantages of agile development

This is the  first post in a series about commissioning software from agile developers, and working effectively with them. Subsequent posts will deal with a number of topics, concentrating on how clients can maximise benefit to themselves by selecting an appropriate company to undertake the development, and how to best work with the developers.

What is this beast called agile development? In brief, agile development combine clients’ business knowledge together with developer skills to realise systems that meet business need. But let’s talk first a bit about what I’ll call conventional software development and then contrast that to agile software development processes.

Many readers will have seen a popular cartoon typifying what can go wrong in software development projects:

tree swing development requirements

Figure 1: A popular conception of software development
(please click to see a larger view)

This is a bleak view of software development. Unfortunately, this is very much the view of the Standish Groups CHAOS Report, an annual survey and publication (that is hard to find without paying large amounts of money). Luckily, a  2012 Standish report appears on the Web. It states:

The 2012 CHAOS results show another increase in project success rates, with 39% of all projects succeeding (delivered on time, on budget, with required features and functions); 43% were challenged (late, over budget, and/or with less than the required features and functions); and 18% failed (cancelled prior to completion or delivered and never used). These numbers represent an uptick in the success rates from the previous study, as well as a decrease in the number of failures. The low point in the last five study periods was 2004, in which only 29% of the projects were successful. This year’s results represent a high watermark for success rates in the history of CHAOS research.

A 2013 survey, which defines project success in a more nuanced way, is provided by Scott Ambler in Dr Dobbs Journal and on his site. Scott discusses reasons for differences between his results and the Standish Group’s in the Dr Dobbs article.

Success rates for conventional projects are low in Scott’s results as seen in the following table. Just to satisfy my curiosity, I added in the Standish 2012 CHAOS survey results in the last line of the table. But please remember that those results don’t differentiate on methodology like Scott’s results.



Successful Challenged Failed
Lean 72% 21% 7%
Agile 64% 30% 6%
Iterative 65% 28% 7%
Ad hoc 50% 35% 15%
Traditional 49% 32% 18%
CHAOS2012 39% 43% 18%

The relative effectiveness of development methodologies across four different success factors was surveyed, and provides further food for thought:



Time/Schedule Budget/ROI Stakeholder Value Product Quality
Lean 5.7 6.0 5.5 4.8
Agile 4.3 4.2 5.6 3.8
Iterative 4.9 4.2 5.6 3.8
Ad hoc 0.0 -0.4 1.9 -1.4
Traditional -0.7 0.5 0.1 1.9

I’m going to be fairly loose: For the purposes of this post, I’ll refer to lean, agile and iterative (in the table above) as agile methodologies, and ignore the differences between these. I’ll  also refer to ad hoc and traditional as conventional  methodologies.

Why do conventional projects perform so poorly? In these projects those commissioning the software may not have a good idea of what they actually need from their projects. So at the time that they specify a product (up-front in the development cycle) they may specify something that is not actually what they need, but rather what they erroneously think they need. This leads to major problems at delivery time.

Instead agile development  allows for specification as the project proceeds. Stakeholders see the product developing and learn more about it and how it can be developed to support their needs as the project progresses (including how the project will address user need, deliver business value,  and maximise ROI).  Together with the developers they work on the development of a system that meets their real needs.

In an agile approach, system development becomes a process of increasing understanding of the product with close communication between developers and stakeholders. By regular communication centred around working software and demonstrations (see figure 2), clients and developers have something concrete to discuss and learn from. Developers can ask how well the system fits client needs, what is the next most valuable thing to add to the developing system, what needs rework or revision, and so on. Clients are able to refine their ideas of what the system should be as it is developed. The end point is that the client is delivered a system that fits their business and user needs and that delivers real business value.

conventional and agile client-developer communication

Figure 2: Client and developer communication
(please click to see a larger view)

As a slightly more technical explanation of figure 2:

With ‘conventional’ projects, client involvement is typified by an up-front specification phase, with acceptance testing happening at the end of the project. In agile project there is no up-front specification, instead the client interacts with the developers in regular cycles as the work planned and then demoed to the client. The two parties act to bring a system to life that as ideally as possible meets the clients business need. In agile projects, in response to seeing the system develop each cycle, the clients refine their own ideas of what the developing system should be as the project progresses. This markedly assists creating a system to address the client’s business needs.

Agile developers demonstrate a working system at the end of each cycle of development, progressively adding more functionality to the system with each cycle. For each cycle the client, with technical advice from the developers, decides what to implement next during the upcoming cycle. This choice is made by the client on the basis of what will, at that stage of development, provide the most business value to the client. This means the functionality with the most business value can be realised early in the project, and that functionality can be rolled out and used as soon as it is developed. Advantageously this provides real business value from the project before it is completed.

This incremental delivery of  functionality providing business value can’t be realised in conventional projects: These projects provide a single delivery at the end of a project when separately-developed layers in a system (see figure 3) are completed integrated.

Agile projects develop and incrementally deliver slices of  functionality  across all layers to provide business value during the project (see figure 3).

conventional layers and agile slices

Figure 3: Big bang delivery and incremental delivery
(please click to see a larger view)

In summary, agile development reduces the risk of up-front specification and ‘big bang’ deliveries which fail to address business need. Rather, agile brings client business knowledge to the development throughout the development to provide better solutions. The agile process is responsive to client needs and developing client understanding of the problem and its solution, and delivers business value as early in the project as possible.

Posted in guide, projects | Leave a comment

Robust systems

How pleasing to have a potential client, a developer who knows us and our work well, sitting in our office, discussing a startup and work for the startup, saying words to the effect of:

“I’m sitting here talking about this job because I know the systems you build are robust.”

Thanks @spotlightkid, you made my day.

Posted in projects, Uncategorized | Leave a comment

Three JISC CETIS reports on
Analytics for Higher Education

CETIS Analytics Series coversWe’ve just finished a lengthy spell of research and reporting that has culminated in three publications in the JISC CETIS Analytics Series. These are:

Links in the list above point to individual download pages.

Crazily, for someone who would like some free time to follow up diverse interests, my mind has now been drifting to two larger writing projects, one a book on the use of Personal Learning Environments in Formal Education, and the other a book on Agile Methods, tentatively called Shuhari, about steps to mastery of agile practices.

We shall see what actually gets written, most of Hedtek’s time is now being taken up by steps close to the release of our assessment system as a webservice.

Posted in Uncategorized | Leave a comment

libUX: Improving user experience in libraries within UK HE

Here’s a report (pdf) we wrote for SCONUL on future user experience of libraries in the UK Higher Education sector.

Notably, the work here includes a small ethnographic survey of UK HE student perspectives on the constraints and affordances of e-libraries by Dave Randall of Unique Adequacy Ltd. We recommend more work of this kind.

From the executive summary:

This report surveys some of the changes that are affecting or will affect users’ experience of library systems (libUX) within Higher Education.

Factors germane to libUX are surveyed in a changing landscape section of the report. These include hardware and platform issues; most importantly, library system use will be changed markedly by adoption of mobile technology, in part driven by decreasing cost and increasing hardware capability. Discovery is a problematic issue for future libraries; their traditional role in providing search facilities is being undermined by global search services including Google and Google Scholar. Further, the increased prominence of electronic resources (including e-books, online serials, and Open Educational Resources) will change the ways libraries need to operate.

It is proposed that various measures need to be put in place to ensure that libraries can respond to these changes. These measures include implementing libUX roles within libraries, including providing training to develop staff placed in these roles, meaningful involvement of users in the development of future library systems, and appropriate funding.

Results of a small ethnographic survey of school leavers and university students and their perceptions of reading, study, and university libraries are included as an appendix.

The report was commissioned by SCONUL, with funding from JISC.

Posted in announcements, libraries, reports | Tagged , | 1 Response

Paper prototyping: mLibrary 2012 presentation

Various participants at M-Libraries 2012 asked for a copy of my invited presentation from today. Here it is for download.

One thing that I don’t touch on in the presentation is the variety of prototypes that could be constructed, the talk only covers paper prototyping, and, particularly, not wireframes, low and high fidelity prototypes. Each has its own advantages, probably the subject of another post if asked about in the comments.

While paper provides significant examples, particularly for encouraging participatory design, at Hedtek we have moved on from paper protyping, preferring to deliver working code and UIs as part of our agile practices. Hey, different stokes for different folks! We are lucky enough to have skilled developers who can modify delivered functionality and user interfaces to order.

But this agile practice is not always the case, recently I’ve been sketching and, through sketches, exploring interfaces with one of our clients who wants to break new ground in computer-supported decision making.

Posted in seminars and keynotes | Tagged , | 3 Responses

Product Launch: Gradient e-Assessment

Gradient main marker page

On the verge of the ALT-C 2012 conference in Manchester, Hedtek are proud to launch Gradient, our new e-assessment system. Gradient provides solutions for tests, assignments and exams, and supports multiple formats, including for handwritten answer books.

Gradient offers:

  • A superb interactive experience for markers
  • Faster and more consistent marking.
  • Enhanced student learning through personalised, actionable student feedback.
  • Feedback is structured for student use, even by less motivated students.
  • Easy reuse and adaption of past feedback.
  • Criterion referenced assessment
  • Faster marking turnaround and improved feedback helps improve National Student Survey scores on assessment and feedback.
  • Built-in quality assurance mechanisms, including mark traceability.
  • Support for institution-specific assessment lifecycles.
  • Ease of use means minimal training requirements.

See the product description.

Gradient is offered as an institutional system, institutionally hosted or hosted by ourselves, and, in a cut down version (without institutional support, but with our superb marking and feedback facilities) over the web as

We’re not stopping here: Future developments will include support for multi-media assessment, peer assessment and Calibrated Peer Review. Ultimately these formative peer assessment techniques will form part of our institutional- and community -focussed Personal Learning Environment.

Posted in Uncategorized | Leave a comment

Statistics: we’re doing well !

Hedtek dev blogSince we started out developer blog five months ago we’ve added 36 posts and had more than 4,600 page views; on average 33 times a day.

Over a similar time frame our open source gems have been downloaded almost 3,800 times.

Meanwhile, our main site (you’re using it) is getting about 1,500 visitors a month; average 50/day.

In the last five months we’ve developed our e-assessment system, Gradient. While developing Gradient we implemented some 340 user stories and user interface features. During this, parts of Gradient were re-implemented up to seven times as we learned more about the domain, our solution, and the advanced technology that we need to use to provide simple and easy-to-use application functionality.

During this we have averaged about 1.23 person days development per user story or user interface feature, but this is heavily skewed by longer times at the start of the project. In effect, as the product owner I know at the start of the day that the top for or five stories in our kanban backlog are likely to be in the demo column by the end of the day.


Gradient is an institutional assessment system that offers significant advantages for teachers, learners, and administrators. adoption.

Gradient (without its institutional features) is  also a web app that individual teachers can use to set, administer, mark assessments and supply feedback to students.  MarkItQuicky runs in the cloud, and is available in beta form at and (soon) Students take assessments via a cloud version of the Gradient Taker Tool or via a VLE (for the latter we are working on Moodle integration at the moment, with BlackBoard following thereafter).






Posted in Uncategorized | Leave a comment

First paid Moodle work

One of our part-time staff is a Moodle Committer (ie someone who helps look after Moodle source code).

Together we are doing our first Moodle job, a small extension to the Moodle Web Services interface. Somewhat noise in the scheme of things, but it helps a friend company, and we’ll contribute the resultant code back to the Moodle community.

More Moodle work most welcome!


Posted in Uncategorized | Leave a comment