Thursday, 27 September 2018

The Riemann Hypothesis Proved..?

Does a Radical New Approach prove The Riemann Hypothesis...?
Only time will tell.

Primes are essential in the contemporary used to secure the internet but the smart money has always been on all primes following the pattern.

Once this Radical New Approach is published, I expect armies of eager postgraduate students to start mining mathematics using this new tool. And this indirect impact on security may be worth watching.

Read more about the proof here...

Wednesday, 7 March 2018

All About It's Tech Up North

For this It's Tech Up North blog, I don my author's hat and meditate upon matters mostly methodological.

Heading up the technical side of , I have many hats ― Agilist, Engineer, Technologist, Analyst, Co-Founder, Shareholder, Director and so on. In my Apache days, we considered hats a lot and ― like many ideas from those times ― this one stuck with me.

The hat as a perspective, as a viewpoint, a way of thinking. Separating concerns. Opinions but loosely held. A hat to be be put on and taken off again, enhancing rather than defining.

It's Tech Up North is a Tech Up North blog but has my personal voice, expressing my personal opinions. Here I wear my author's hat.

Friday, 2 March 2018

Sunny Memories on a Snowy Day

Some photos from my time on site in . was engaged there on a project involving cryptography on mobile platforms.

Cambridge in Autumn

On Site In Cambridge, Autumn 2016 ― sunny times

Monday, 29 January 2018

Tech Up North Ltd

Last post back in 2012.

Been a bit of a roller coaster ride for me in those five years. Maybe I'll share some observations about those years a little later.

Today — though — in this new year of 2018 I'd like to talk about the future.

— the micro-company I co-founded —is just over a year old and I'll be rebooting this blog with similar content but owned and operated under the Company banner.

Hope you'll continue to find my words of interest.

Thanks for reading,
Robert Burrell Donkin
Director, Tech Up North Ltd

Tech Up North Ltd 
Train • Engineer • Develop 
Registered in England and Wales 
Company Number 10340164 
Registered Office Windsor House LE4 9HA

Sunday, 5 February 2012

Another Charity Day: Maven Training In Manchester

Manchester in Winter, 2012

In January, I took the train to , to visit my friends at .

Manchester in Winter, 2012

HedTek loves but regularly works with and .
So, this — the second of my — would be a Maven master class.

Manchester in Winter, 2012

The session was hands on: after a short discussion around slides focusing on concepts and philosophy, we dived into some real code.

Manchester In Winter 2012

For the morning, I brought along a mystery code base.

Maven's declarative nature means that it's possible to learn a lot about a novel code base from its project build. We started by applying comprehension tips and techniques.

Manchester in Winter, 2012
Manchester in Winter 2012

We completed the morning by moving on to wiring a new into the project. are surprisingly easy to create, and illustrate well how Maven works behind the scenes.

Manchester in Winter, 2012

In the afternoon, we used Maven to create a new project from scratch: picking on . We finished by reviewing some of the builds HedTek already deals with.

Slides

Monday, 16 January 2012

An Extreme Hour At Agile Yorkshire

The qualities that the audience brings — enthusiasm, energy and engagement; experience, knowledge and ideas — are the keys to a successful participatory session. So, thanks to all the Yorkshire Agilists who braved the January gloom for our . And a special shout from me to Grant Crofton, who paired-up with me as co-host.

An Extreme Hour is a process miniature illustrating facets of XP. Famously XP leavens a tiny process with practices and philosophy, tools and techniques. XP teams often add optional extras into the mix, for example iterations, which occasionally obscure XP's essential simplicity.

One hour flows by fast: it makes sense to select themes and arrange the focus on them. This time, we stripped down the process to essentials and set out to challenge and through in the between and developers. Our rules-for-today required that each story be written on one card using the classic "As a, I want" template.

Team building happened first and fast: focusing relations within, and limiting ties between, teams. Next, customers were separated and grouped, presented privately with an open, undirected product challenge, then left to brainstorm. This set up customers as domain experts — limiting independent developer knowledge.

The twist thrown into the mix this time was . Teams were challenged to create dynamic interfaces from paper, card and stickies using scissors and pens. This went really well — though testing wasn't feasible, was: with the driver operating the pens and scissors, and the navigator owning the story card.

I left happy.

Materials are available to remix and reuse under the CC-by-3.0.

Monday, 9 January 2012

Some Extreme Programming

Essentials

Software development fails to deliver, and fails to deliver value. This failure has huge economic and human impact. We need to find a new way to develop software.

Kent Beck, Extreme Programming Explained

Extreme Programming (XP) is a , , influential not only as a highly successful process (for smaller projects) but for the innovative practices (tools and techniques) described and the philosophy espoused.


XP values

For small projects, Agile, extreme programming and high-level programming languages are key practices because coding is the dominant activity for small applications.

Capers Jones, Software Engineering Best Practices


XP believes in

  • rapid feedback,
  • assuming simplicity,
  • incremental change,
  • embracing change and
  • quality work.

The exact limits of XP aren't clear yet. But there are some absolute showstoppers that prevent XP from working — big teams, distrustful customers, technology that doesn't support graceful change.

Kent Beck, Extreme Programming Explained

XP practices


We can drive ourselves crazy with expectation. But by preparing for every eventuality we can think of, we leave ourselves vulnerable to the eventualities we can't imagine.

Kent Beck, Extreme Programming Explained


XP separates traditional project management into

XP is a lightweight, efficient, low risk, flexible, predictable, scientific, and fun way to develop software.

Kent Beck, Extreme Programming Explained

Selected

Seed
Read
Feed

Sunday, 1 January 2012

About Business Value And Issue Trackers

Pull scheduling allows developers to grab work from a . This way of team working is efficient — flowing around impediments — and effective — developers understand software — but is not necessarily well aligned with the business.

Maintaining A Backlog

I hear many people complain that it is hard to define business value. So they won't do it. Or they won't try any harder to do it.

Joseph H. Little, Defining Business Value

Software features vary in value (to the business). To align the flow (of features) to maximum business value, empower a with decisiveness to prioritize the backlog. Healthy software has business value, so factor in gradual repayment of . Over time feature valuations drift, either in response to an evolving business environment or as domain knowledge is won. So, review valuations regularly.

Tracking The Backlog

An information radiator displays information in a place where passersby can see it. With information radiators, the passersby do not need to ask questions; the information simply hits them as they pass.

Alistair Cockburn, Agile Software Development

For co-located teams, the physicality of a board is great, acting as an . Where distribution favours a software solution, use a big screen to radiate backlog and activity feeds to those co-located.

A good issue tracker is a flexible tool, and convenient for backlog tracking. When used so, invest in careful configuring: though similar in structure, an Agile backlog is not a list of defects, differing in several subtle — but significant — semantics.

As the team learns to create higher quality software, the number of defects should fall over time. As the team delivers business value, demand — and the backlog — should increase. Successful teams should expect these queues to move in opposite directions over time: defects shrinking but the backlog growing.

Issue Priority Is Not Business Value

Most issues trackers include a priority quality. For example, priority is selected from BLOCKER, major, minor, trivial and so on. These traditional names carry with them baggage from conventional bug and release management.

This issue priority may differ radically from business value. Behaviour considered unacceptable when wearing a test- and release-hat might reasonably be given a high issue priority, but only the view under a business hat shows the business value delivered by work on this issue.

Avoid conflating these concepts: add a new business value field. Whimsical names (for example gold >> silver >> iron >> paper >> blue skies) are memorable, and help avoid misunderstandings and misuse.

An Example

5 minutes might sound like a long time to wait for a screen to load. From the testing perspective, this might be a seen as a major issue.

However, this does not necessary mean that improved start-up time would bring major business benefit. A business might expect an employee to open the screen in the morning, and then go to make their coffee. The screen would remain open all day, closing again only at night. For this business, value lies in responsiveness and stability but not start-up time. Lengthy start-up would then be a major issue with paper business value.

In this case, reasonable valuations reached wearing tester and business hats would result in seemingly opposing assessments — until understanding that each measures a different quality. Fitting both qualities into a single field encourages wasteful conflict where there should be harmony.

Thursday, 22 December 2011

A Charity Day of Agile Coaching

Bradford to London, aboard The James Herriot

The magnificent Grand Central swept me to London last week for my first .

Bradford to London, aboard The James Herriot

Thanks to Rob Dyke for inviting me to visit and for generously pledging £250 to The Woodland Trust, and to the team for such a warm welcome in this cold weather.

Bradford to London, aboard The James Herriot
sustains the community, so we share interests in the open source health space (as well as ). Rob and I met through the oss-uk-health group. Exciting times, with doors starting to open.

Table in King's Cross Hub
, King's Cross is a funky space, a stones throw from the famous station.
Grand Central HST London Kings Cross
Stairs in King's Cross Hub
00_hub kings x_panoramic view ground floor

We were booked into the board room — an interesting space with plenty of glass for drawing on.

0063_HKX_detail_glass writing
The board table filled most of the space, imposing some physical limits on our activities. We improvised and adapted to this physicality.

The team are just starting Scrum. Our morning focused on building skills and knowledge. The inaugural followed, after lunch.

For the morning, I brought along pick-n-mix. Before each session, we played decision poker to pick one from five themes:

Thumb voting then picked one activity from the themed mix. One red card session on user stories was included.

We hit our timeboxes, squeezing in five sessions each structured as {5m plan, 20m do, 5m reflect}, with time for breaks. The physicality of my ladybird timer proved popular: personal, quirky and fun.

After lunch, I observed the meeting, and offered some feedback, before we all left tied but happy.

Some Testing

Essentials

Optimism is an occupational hazard of programming. Feedback is the treatment.

Kent Beck

TDD seemed so revolutionary when it test infected Jakarta (and most of the rest of Apache). This test automation proved a notable factor in the later success of Tomcat, Struts, Ant, Maven, Commons (and all the rest).


Tests bridge the gap between the language of the customer and the languages of software. encourages alignment by starting with the customer then working inwards towards code.



Fine-grain unit tests execute fast, exercising a unit in isolation. Loosely coupled, cohesive designs are easier to unit test, so unit testing rewards good object-scale design.


Coarse-grain tests, exercising integrated components execute much more slowly, even with appropriate techniques (for example, switching to an in-memory store). Component-scale integration tests encourage cleaner, more reusable API designs.


The outermost layer exercises assembled applications. Fidelity to customer configuration is essential, and often means filling heavyweight stores with data. Set up and tear down costs are almost always high for enterprise applications.


Reasonable coverage using slow running integration and application layer tests costs. Avoid disrupting development flow: separate integration and application suites, and run them outside this flow. Consider triggering after each . To avoid maintenance issues, integration test selectively, invest in good fixtures and use the language of the customer.


A wide variety of open source tools continue to emerge, with sweet spots spanning the space. So spike.

Tools like and Fitness use the language of the customer, a fine match for outer (application and integration) layers. Mocking frameworks efficiently create test doubles to isolate the unit from its environment, and to efficiently verify behaviour (but not at the same time as state).

Efficient tools for special topics abound, for example web applications, load testing, performance testing, Swing, data access, JavaScript and so on...

Selected

Seed
Read
Feed

Search This Blog