Category Archives: Information Systems

Suits you?

Last night I went to a ‘Product Tank Birmingham’ workshop on ‘Empathy Mapping’. As an exercise, we looked at ‘a product meeting group’ and tried to identify its customers. There was a brief discussion about ‘Product Owners’ (from agile software development) and ‘Product Managers’ who often have a more marketing-led approach. Someone then commented on what ‘Product people’ think. I found I didn’t agree. I reflected on the difference between Product Owners (in this context: me), who care about giving people the product they want and Product Managers, who seem to care more about people’s relationship with the product.

I realised there is a half-way house and I have not, to date, worked in it. My experience in agile software development has been about “custom” development of software products for small teams with a shared view of what they want. I’ve realised for a while that my experience is very different to those Product Owners who have to develop a more generic product to ‘optimise’ across a set of potential or actual customers who have differing needs. There is an extra role there which is far more like my understanding of Product Management. I think the key difference is the need to correctly judge the closeness of fit needed to achieve mass market appeal vs the bespoke tailoring trade that I’ve worked in.

Early in my career, I worked as a programmer on a software package for pharmaceutical companies. We coded to specifications provided by 2 people, a salesman and our technical manager, who both travelled the world visiting customers’ sites. Looking back, I think the salesman was much better at identifying the features that would be valued by most customers. Is marketing USEFUL?

RUNOFF another copy?

I was telling a story about my first job a couple of days ago. I was an ‘applications programmer’ at Cambridgeshire College of Art and Technology. There was an Argentinian lecturer who knew our systems. He asked if his wife could use the computer centre facilities to write up her research thesis during the Summer holidays. We were casual users of a text processing ‘tagging language’ for documentation. It was called DSR, Digital [Equipment Co.] Standard Runoff, so my colleague John suggested she used that. The ‘typing department’ had some fancy new ‘word processors’ (I think they were Wang) but we didn’t have any authority over them and wouldn’t be able to help her with problems. We also had doubts about whether they had the capacity for a whole thesis.

So it was that John and, in his absence, I provided occasional help to a charming, intelligent Argentinian woman during the outbreak of the Falklands War in 1982, while the British press ramped up the hatred of British idiots against the entire Argentinian nation. She was the first Argentinian I’d ever met and it was the first time I had any indication that fascism could also infect the UK or was personally shamed by the state of our newspapers. I remember us scooping up some hate-filled tabloid front page and dumping it, seconds before our guest arrived.

In later jobs I learned of Unix roff, nroff and troff and came to assume that Runoff was DEC’s version of the Unix tools. Today I discovered that isn’t true. DEC’s Runoff came from the common ancestor of the Unix tools, Runoff on CTSS then Multics (1964.)
“types out text segments in manuscript form.”

https://en.wikipedia.org/wiki/TYPSET_and_RUNOFF

CTSS was also the original home of LISP, ALGOL and the text editor QED, the predecessor of ed, vi and vim.

Tooling for Clojure and ClojureScript

[:ChangeLog
(:v0.2
“recognise that ‘resolving dependencies’ and ‘build’ are different operations.”
“Add conversion tools between project.clj & deps.edn”)
(:v0.3
“Remove CLI tools described as a build tool comment.”)]

WARNING
I still have much to learn about ClojureScript tooling but I thought I’d share what (I think) I’ve learned, as I have found it difficult to locate advice for beginners that is still current. This is very incomplete. It may stay that way or I may update it into a living document. I don’t actually have much advice to give and it’s only about the paths that have interested me.

Clojure development requires:

  • a text editor,

and optionally,

  • a REPL, for a dynamic coding environment
  • dependency and build tool(s).

The absolute minimum Clojure environment is a Java .jar file, containing the clojure.main/main entry point, which can be called with the name of your file.clj as a parameter, to read and run your code. I don’t think anyone does that, after they’ve run it once to check it flies.

Based on 2 books, ‘Clojure for the Brave & True’ and ‘Living Clojure’, my chosen tools are emacs for editing, with CIDER connecting a REPL, and Leiningen as dependency & build tool. ‘lein repl’ can also start a REPL.
Boot is available as an alternative to Leiningen but I got the impression it might be a bit too ‘exciting’ for a Clojure noob like me, so I haven’t used it yet.
CIDER provides a client-server link between an editor (I’m learning emacs) and a REPL.

If you use Leiningen, it comes with a free set of assumptions about development directory structure and the expectation that you will create a file, project.cli in the root directory of each ‘project’, containing a :dependencies vector. Then magic happens. If your change the dependencies of your project, the config fairies work out everything else that needs changing.

Next, I wanted to start using ClojureScript (CLJS.) I assumed that the same set of tools would extend. I was wrong to assume.
Unfortunately, CLJS tooling is less standardised and doesn’t seem to have reached such a stable state.

In ‘Living Clojure’, Carin Meier suggests using cljsbuild. It uses the lein-cljsbuild plugin and the command:

lein cljsbuild auto

to start a process which automatically re-compiles whenever a change is saved to the cljs source file. If the generated JavaScript is open in a browser, then the change will be shown in the browser window. This is enough to get you going. It is my current state.

I’ve read that there are other tools such as Figwheel, now transitioning to ‘Figwheel Main’ which hot-load the transcribed code into the browser as you change it.
There is a lein-figwheel as well as a lein-cljsbuild, which at least sounds like a drop-in replacement. I suspect it isn’t that simple.

There are several REPLs, though there seems to be some standardisation around nrepl.
It was part of the Clojure project but now has its own nrepl/nrepl repository on Github. It is used by Clojure, ‘lein repl’ and by CIDER.

There is something called Piggieback which adds CLJS support to NREPL. There is a CIDER Piggieback and an NREPL Piggieback. I have NO IDEA! (yet.)
shadow-cljs exists. Sorry, that’s all I have there too.

At this point in my confusion, a dependency issue killed my tool-chain.
I think one of the config fairies was off sick that day. The fix was a re-install of an emacs module. This forced me to explore possible reasons. I discovered the Clojure ‘Getting Started’ page had changed (or I’d never read it.)
https://clojure.org/guides/getting_started

There are also (now?) ‘Deps and the CLI Tools’ https://clojure.org/guides/deps_and_cli and https://clojure.org/reference/deps_and_cli

I think these are new and I believe they are intended to be the beginners’ entry point into Clojure development, before you dive into the more complex tools. There are CLI commands: ‘clojure’ and a wrapper that provides line-editing, ‘clj’
and a file called ‘deps.edn’ which specifies the dependencies, much as ‘projects.clj’ :depencies vector does for Leiningen but with a different syntax.

I’m less clear if these are also intended as new tools for experts, to be used by ‘higher order’ tools like Leiningen and Figwheel, or whether they will be adopted by those tools.

[ On the day I wrote this, I had a tip from didibus on clojureverse.org that there are plugins for Leiningen and Boot to use an existing deps.edn,

so perhaps this is the coming future standard for specifying & resolving dependencies, while lein and boot continue to provide additional build capabilities. deps.edn refers to Maven. I discovered elsewhere that Maven references existed but were hidden away inside Leiningen. It looks like I need to learn a little about Apache Maven. I didn’t come to Closure via Java but I can see the advantages to Java practitioners of using their standard build tool. I may need to drop down into Java one day, so I guess I may as well learn about Java-land now.

Also via: https://clojureverse.org/t/has-anyone-written-a-tool-to-spit-out-a-deps-edn-from-a-project-clj/2086, there is a https://github.com/hagmonk/depify, which ‘goes the other way’, trying it’s best to convert a project.clj to a deps.edn. Hopefully that would be a ‘one-off’? ]

I chose the Clojure language for its simplicity. The tooling journey has been longer than I expected, so I hope this information cuts some corners for you.

[ Please let me know if I’m wrong about any of this or if there are better, current documents that I should read. ]

A new target for Software Developers: Sensei.

I originally wrote this as an answer to a question on Quora but I’m increasingly concerned at the cost of higher education for young people from families that are not wealthy. I had parents who would have sacrificed anything for my education but I had clever friends who were not so fortunate. The system is bleeding talent into dead-end jobs. Below, I consider other models of training as I hope it might start a conversation in the technology community and the political infrastructure that trickles money down into it.

Through learning about ‘Agile’ software development, I became interested in related ‘Lean’ thinking. It borrows from Japanese cultural ideas and the way the martial arts are taught. I think the idea is that first you do, then you learn and finally you understand (as illustrated by the film ‘Karate Kid’.) That requires a ‘master’ or ‘Sensei’ to guide and react to what s/he sees about each individual’s current practice. It seems a good model for programming too. There may be times when doing is easier if you gain some understanding before you ‘do’ and advice and assistance with problem solving could be part of this. I’m not alone in thinking this way, as I see phrases like “kata” and “koans” appearing around software development.

I’ve also seen several analogies to woodworking craft which suggests that a master-apprentice relationship might be appropriate. There is even a ‘Software Craftsmanship’ movement. This could work as well in agile software development teams, as it did for weavers of mediaeval tapestries.

A female Scrum Master friend assures me that the word “master” is not gendered in either of these contexts. Of course, not all great individual crafts people make good teachers but teams with the best teachers would start to attract the best apprentices.

If any good programmers aren’t sure about spending their valuable developer’s time teaching, I recommend the “fable in novella form” Jonathan Livingston Seagull, written by Richard Bach, about a young seagull that wants to excel at flying.

Small software companies ‘have a lot on’ but how much would they need to be paid to take on an apprentice in their development teams, perhaps with weekly day-release to a local training organisation? I’d expect a sliding scale to employment as they became productive or were rejected back into the cold, hard world if they weren’t making the grade.

Model Software

Today, I had to stop myself writing “solving the problem” about developing software. Why do we say that? Why do software people call any bounded area of reality “the problem domain”?

My change of mind has been fermenting for a while, due to modelling business processes, learning about incremental, agile software development and more recently writing and learning functional programming. In the shower this morning, I finally concluded that I think software is primarily a modelling medium. We solve problems using the models we build.

Wanting to create another first-person shooter game or to model the fluids in a thermo-nuclear reactor are challenges, not problems. We build models of systems we have defined and the systems don’t even have to be real. I read a couple of days ago that a famous modern philosopher said our world is made of both reality and our ideas. Assuming the computer hardware is real, the software can model either reality or our imagination; our chosen narrative.

‘Digital’ gets everyone working with software models instead of reality. Once everyone lives inside the shared model, when does it become our reality?

Or when did it?

What I Don’t Know

A Wiki is sometimes described by the ‘backronym’ “What I Know Is”.

Recently I’ve been using Quora. You can ask a question or, if you see someone else’s question and think you know the answer, you can reply. Over time, you become associated with areas of knowledge that interest you. The obvious equivalent to the Wiki translation would be “What I want to know is” but you always have to use social systems to understand their dynamics. I didn’t ‘get’ Twitter until I’d used it for some time because at first, nothing happens.

I discovered Quora is really about “What I Don’t Know Is”. It’s obvious that by asking a question, you declare a ‘known unknown’  but human ignorance goes deeper than that. As someone who tries to answer questions, you learn about the gaps in your own knowledge, that you are unable to explain a concept you thought you understood and that there are things many people don’t know or understand that you had assumed were obvious to everyone. We all struggle to provide good, clear, concise, unambiguous questions and answers, because we don’t know everything.

I discovered that other people’s thinking and motivations are often very different from mine. I wasn’t aware of how much more of a rush many young people are in to ‘be a star’ at something, often without much understanding of what that something is. I never hurried or set targets, so I wasn’t aware of how much I’d learned about life, until I read some of their questions.

A journey of a thousand thoughts can begin with a single question. The view from the far end of that trail may be different. We need to be curious about everything around us rather than too ambitious to arrive at a fixed destination by the fastest or shortest route. You can dream about the future but it may not arrive packaged as you expect it and pieces may be missing. Plan your early moves, travel at a sustainable rate and stay aware. I’m worried that many of the young hopefuls on Quora will burn-out before they get close to their targets and become disillusioned.

I’m still hungry to learn. There is so much I don’t know and it’s growing all the time.

Reality has Levels

It’s been a while since I blogged. I’ve been busy.

A major theme emerging from ‘writing my book’ is that we humans are very bad at confusing our models of reality with the reality we are modelling.

I started planning with the ‘Freemind mind-mapping tool for hierarchical brains’ before finding my own creative process had a network architecture and discovering ‘concept mapping’ which uses graphs to represent concepts and propositions. I saw that graphs were what I needed and decided to experiment with building my own software tools from bits I had lying around.

I didn’t have a current programming language, so I set out to learn Clojure. Being a Lisp, Clojure uses tree-structures internally to represent lists and extends the idea to abstractions such as collections but the only native data structures available to me appeared to be 1-dimensional.  I confidently expected to be able to find ways to extend this to 3 or more dimensional graphs but despite much reading and learning lots of other things, I’d failed to find what I was looking for. I had in mind the kind of structures you can build with pointers, in languages like ‘C’. There are graph libraries but I was too new to Clojure to believe my first serious program needed to be dependent on language extensions, when I haven’t securely grasped the basics.

This morning, I think I ‘got it’. I am trying to build a computational model of my graphical view of a mathematical idea which models a cognitive model of reality. There was always scope for confusion. Graphs aren’t really a picture, they are a set of 1-dimensional connections and potentially another set of potential views of those connections, constructed for a particular purpose. I was trying to build a data structure of a view of a graph, not the graph itself and that was a really bad idea. At least I didn’t get software confused with ‘actual’ reality, so there’s still hope for me.

Yesterday, I used Clojure/Leiningen’s in-built Test-Driven Development tool for the first time. It looks great. The functional model makes TDD simple.