Down with management!

Allan Kelly from Allan Kelly Associates

ConversationiStock_000007409052XSmall-2018-02-14-10-44.jpg

Si: Welcome Peter, thank you for taking the time to attend this annual performance review

Peter: As long as you know I don’t want to be here, performance reviews are pointless, I told that to my manager Roger. I should be at my desk coding.

Si: Yes, I understand your position, in fact many of us sympathise with it, including Roger and myself

Peter: Well, good, does he also agree that management is a waste of time? If we were really following Agile the way we should then Roger wouldn’t be getting in the way all the time and I could write more code.

Si: Yes, well, we’ve had that feedback from other people and the company is committed to change. In fact, one of the things I wanted to speak to you about today was to tell you Roger is stepping aside.

Peter: What?

Si: Yes, Roger is undertaking retraining and will become a Product Specialist, he himself rejected the title Product Manager because he doesn’t see the need for Managers and even refused the title Product Owner because he doesn’t feel he can “own” something that is a community effort and is ultimately owned by the company shareholders.

Peter: Wow… he has been listening to me?

Si: Yes, in my long conversations with him he has spoken many times of the points you have been making. Of course as part of the management team it wouldn’t have been right for him to speak about his changing views too publicly lest people wonder what was happening.

One of the things I wanted to discuss with you today was how we go about distributing Roger’s other responsibilities. As one the longest serving employees Roger suggested you would have the best insights.

Peter: Right, erh, so what responsibilities are these? – apart from asking me “how long will it take?”

Si: Well some relate to the product. As Product Specialist he will continue to support sales staff making customer visits, he will continue administer the backlog, prioritise work in the planning meeting and draw-up the product roadmap – although he wants to involve more people and change the concept of a roadmap. He plans to increase the number of customer visits, competitor analysis and market scanning activities he has been doing already.

Peter: Good, we need a proper product owner, he was doing the role anyway but didn’t have enough time.

Si: Well yes, in fact he has also requested that you and the other engineers accompany him on customer visits in future.

Peter: What? – but our customers are everywhere but here!!! Saudi Arabia, Finland, Argentina, USA… it takes days to get to those places, I’m needed here, I need to be coding!

Si: Well I’ll let the two of you come to a decision on that. Right now we need to redistribute Roger’s work.

There are the administration matters, signing off holiday, arranging sabbaticals, maternity/paternity leave; the new monthly check-points replacing annual performance reviews need to be staffed. There is a lot of work around contractors, time-sheets, extensions and terminations, to be honest there are constant political battles over the number of contractors and whether we should be using them at all. Personally, I believe these changes will abolish office politics but some people think I’m being naive.

Anyway, a lot of this work could be for someone like myself in HR…

Peter: But that will slow everything down! HR is never responsive and most of them – unlike yourself – don’t know one end of a code stack from another

Si: Yes, quite right, HR is atrociously understaffed so we take forever to do anything, and many of my colleagues just aren’t close enough to the teams – frankly they don’t understand technology.

For those reasons the company is also closing the HR department. The work will be distributed to the teams. So my colleagues and I are all being made redundant. Some larger teams, such as yours, will be allowed to hire “Talent specialists” to help with recruitment matters and I hope to secure a such a job myself. But that also means members of your team will need to interview and select their own Talent Specialist. I expect you’ll be on the interview panel, I hope you will see the depth of my experience.

Peter: O, but we are all so busy coding, that will slow us down! And we don’t know anything about recruiting HR people. Can’t Roger arrange that before he leaves?

Si: Roger’s re-assignment is immediate, he insisted on it. I suggest you and your colleagues get started on selecting your Talent Specialist as quickly as possible.

Still, many of the things I just listed will not fall under the Talent Specialists remit. A self-managing team really should manage a lot of those things itself. The Talent Specialist will be there for staffing issues, CV filtering, negotiating with recruitment agents, diversity monitoring, visa applications, university recruitment fairs, exit interviews, legal issues, and so on.

Peter: Right, well I’m sure out team can dispense with a lot of the administration, we can trust one another to take holiday responsibly.

Si: Quite so, I’m sure you can organise away a lot of the admin work but there will be a rump.

Peter: Could we bring back the Scrum Masters?

Si: Well the Scrum Masters we had were always at pains to point out they were not managers or administrators – I know they are in some other places. Plus, they said they “did themselves out of a job” in the end and recommended their own removal.

Peter: Arh… I remember, I guess we will share the administration around the team. We can work out a process for that – the same as we do in planning meetings.

Si: Remember as you do that some of your team may need management training

Peter: What?

Si: Management, even administration, has its own on standards, rules, jargon, if members of your team are going to do administration and management work, let alone talk to others doing it then they need to know their CapEx from their OpEx, their 4 Ps from their 5 Forces, front-of-house from back-of-house, what you can and can’t say in an exit interview, a SWOT analysis from a …

Peter: Yes, yes I get it, a lot of mumbo jumbo if you ask me…

Si: All the same, is it fair to throw people in at the deep-end? Shouldn’t we help them learn if they want to?

Moving on next we come to Roger’s role in the hierarchy. Sharing company information down to the team and team information up the chain. Plus annual strategy meetings, quarterly reviews, product portfolio boards, key customer engagement.

Peter: We have Slack and Wiki’s so I’m sure we can manage the information alright.

Si: Arh… well, when we rolled this program out in Norway some of the teams tried just that. In a couple of months most of the team members were complaining about information overload. I believe the quote was “How can you expect me to do any coding when Slack keeps interrupting me?”

Peter: Arhhh.

Si: And the Norwegian executives felt they never got a consistent message from the teams because different people would turn up to quarterly reviews each time while strategy sessions started to resemble a Stackover flow argument. Some customers complained that they no longer had a point of contact or got conflicting messages. And lets not even talk about the auditors.

Peter: Well the thing is, none of us have been trained in Strategy or, what did you call it? Portfolio review?

Si: Good thinking, I guess one of Roger’s strengths was the time he spent studying that on his American MBA. Do you want to arrange a coupe of days training in strategy and portfolio review for your team?

Peter: Erh, I’m not sure I know enough to book a training course, and isn’t that going to take people away from coding?

I mean the whole team, all 10 of us, out for 2 days training? And the people going to attend meetings with other departments and teams?

Si: Yes of course it is, but you will be self-managing. The team won’t have anyone else.

And mentioning the team, there is also another issue you’ve raised yourself in the past. Here we are, two very similar males discussing this. In fact your whole team is quite like the two of us. The team are going to have to challenge themselves to improve their diversity.

Peter: Right…

Look, we’ve been here half-an-hour and haven’t started even reviewing my performance, will this take much longer? I’ve got code to write.

Si: Well, there is quite a bit more of Roger’s work to discuss, plus his boss, Jane, is also stepping aside so we need to reconvene with people from the other teams to allocate her remaining work.

Peter: If we are self-managing, could we decide to employ a specialist to pick up a lot of this work?

Si: I expect you could, you’d need to put some costings together.

Peter: Right, I’ll talk it through with the team and see if we can hire a secretary.

Si: Good idea, although the secretary is going to need more than just typing skills.

Peter: Sure, secretary might be the wrong job title. We need someone with skills who we can trust to make these decisions, someone with experience.

Si: Although, you know, such a person may become a bit of a gate-keeper to the team

Peter: Certainly, thats what we need, we don’t want interruptions!

Si: Well, the problem with a gate keeper is that they decide what goes through the gate and what does not. That gives them a degree of power.

And if someone is picking up all the left over work, making decisions for the team, and controlling access to the team, and information flows into and out of the team…

Peter: Yes, is there a problem? That all sounds good to me, this gate keeper will have the power to defend the team

Si: Well… what I was about to say is such a person might be seen by some as having authority… and how will the team members feel about someone else deciding what is told to others?

Peter: Well, we could review their decisions and tell them what to do

Si: Yes… well, that might be seen as a lacking trust or even micro-manegement…

The post Down with management! appeared first on Allan Kelly Associates.

MyTech once again a roaring success!

Paul Grenyer from Paul Grenyer

Held by Inspired Youth Projects, My Tech 2018 was another successful meeting of tech employers and burgeoning tech talent.

Naked Element was proud to support the event, as always, and our developers really got a lot out of it too! "The MyTech Inspired Youth event brought together some of the great local tech companies and organisations including EposNow, Breakwater IT and Tech East” said our developer Henri Keeble, “It was was great talking to the students about what it is we do at Naked Element - the technically minded students showed a lot of interest. We were able to give some insight into what a career in software may look like, but also speak about the different routes we'd taken to get to where we are now, with my colleague Jack and myself having very different experiences. We were able to offer some advice we wish we'd known! It was also good to see those who were uncertain of their future career goals taking an interest in the various companies that were present.”

The day started with employability workshops and employer speed networking sessions, designed to help students get an idea of the variety of opportunities available to them.
For those who felt a little anxious at the idea of networking, there was a new ‘no pressure’ session for a more relaxed way to talk to employers. Our apprentice software developer Jack Rogers found it interesting to hear more about what students were considering after high school. “I enjoyed listening to students that were passionate about their future after finishing their GCSE's. Some of the students were also not certain what they were going to do, so it was very helpful to explain the decisions I made. It was interesting to see the diversity of career paths of the young people attending and the choices that each of them are making, as well as seeing how technology has advanced as more and more students are showing an interest towards it.”
The second half of the event was dedicated time for older students who had their sights set on career opportunities, training or apprenticeships within the tech industry and it as clear that those who attended found the day valuable. Supporting the new wave of techies in the region has long been a significant part of what Naked Element do. Director Paul Grenyer explains “It’s very important to inspire and encourage students to choose a career in tech in Norfolk, as there is increased demand for digital skills and this looks set to continue for a considerable time to come - Norfolk companies contact me weekly looking for developers and people with supporting digital skills.” Paul is also involved in a work group to help address the skills shortage in our local area. “TechNation has put Norwich firmly on the map when it comes to innovative tech companies” he says “and these companies will be looking to grow over the next 5+ years and will require a local workforce to support that growth. That’s why events like My Tech are so crucial.”

Xanpan – free eBook now!

Allan Kelly Associates from Allan Kelly Associates

Hypothesis: If I offer people a free copy of my Xanpan eBook (suggested price $17.50) then people will sign up to my newsletter list – which carries my blog posts, event lists and other news.

Test: Blog it, Tweet it, etc., wait a month and count the subscribers.

Use the form below and check your mailbox for confirmation and links.

Subscribe to our mailing list

* indicates required



Email Format


The post Xanpan – free eBook now! appeared first on Allan Kelly Associates.

Compiler validation is now part of history

Derek Jones from The Shape of Code

Compiler validation makes sense in a world where there are many different hardware platforms, each with their own independent compilers (third parties often implemented compilers for popular platforms, competing against the hardware vendor). A large organization that spends hundreds of millions on a multitude of computer systems (e.g., the U.S. government) wants to keep prices down, which means the cost of porting its software to different platforms needs to be kept down (or at least suppliers need to think it will not cost too much to switch hardware).

A crucial requirement for source code portability is that different compilers be able to compile the same source, generating code that produces the same behavior. The same behavior requirement is an issue when the underlying word-size varies or has different alignment requirements (lots of code relies on data structures following particular patterns of behavior), but management on all sides always seems to think that being able to compile the source is enough. Compilers vendors often supported extensions to the language standard, and developers got to learn they were extensions when porting to a different compiler.

The U.S. government funded a conformance testing service, and paid for compiler validation suites to be written (source code for what were once the Cobol 85, Fortran 78 and
SQL validation suites). While it was in business, this conformance testing service was involved C compiler validation, but it did not have to fund any development because commercial test suites were available.

The 1990s was the mass-extinction decade for companies selling non-Intel hardware. The widespread use of Open source compilers, coupled with the disappearance of lots of different cpus (porting compilers to new vendor cpus was always a good money spinner, for the compiler writing cottage industry), meant that many compilers disappeared from the market.

These days, language portability issues have been essentially solved by a near mono-culture of compilers and cpus. It’s the libraries that are the primary cause of application portability problems. There is a test suite for POSIX and Linux has its own tests.

There are companies selling compiler C/C++ test suites (e.g., Perennial and PlumHall); when maintaining a compiler it’s cost effective to have a set of third-party tests designed to exercise all the language.

The OpenGroup offer to test your C compiler and issue a brand certificate if it passes the tests.

Source code portability requires compilers to have the same behavior and traditionally the generally accepted behavior has been defined by an ISO Standard or how one particular implementation behaved. In an Open source world behavior is defined by what needs to be done to run the majority of existing code. Does it matter if Open source compilers evolve in a direction that is different from the behavior specified in an ISO Standard? I think not, it makes no difference to the majority of developers; but be careful, saying this can quickly generate a major storm in a tiny teacup.

Ideas on how lexing will work in Pepper3

Andy Balaam from Andy Balaam's Blog

I am trying to practice documentation-driven development in Pepper3, so every time I start on an area, I will write documentation explaining how it works, and include examples that are automatically verified during the build.

I’ve started work on lexing, since you can’t do much before you do that, but in fact, of course, I need to have a command line interface before I can verify any of the examples, so I’m working on that too.

Lexing is the process that takes a stream of characters (e.g. from a file) and turns it into a stream of “tokens” that are chunks of code like a variable name, a number or a string. (There is more on lexing in my mini programming language, Cell.)

My thoughts so far about lexing are in lexing.md, and current ideas about command line interface are at command_line.md. All very much subject to change.

Headlines:

  • Ordinary programmers can write their own lexing rules.
  • Operators (functions like “+” that find their arguments on their left and right, instead of between brackets like normal functions) are defined at the lexing phase, so any symbol (e.g. “in”) can be an operator if you want.
  • Anything you might want to do with a pepper program, including running it, compiling it, packaging it for an distribution system, should be available as a sub-command of the main pepper3 command line.
  • The command is “pepper3”, never “pepper”. If a new, incompatible version comes out, it will be called “pepper4”, and they will be parallel-installable, with no confusion.

Deleting commits from the git history

Andy Balaam from Andy Balaam's Blog

Today I wanted to fix a Git repo that contained some bad commits (i.e. git fsck complained about them). [I wanted to do this because GitLab was not allowing me to push the bad commits.]

I wanted the code to look exactly as it did before, but the history to look different, so the bad commits disappeared, and (presumably) the work done in the bad commits to look like it was done in the commits following them.

Here’s what I ran:

git filter-branch -f --commit-filter '

    if [ "${GIT_COMMIT}" = "abdcef012345abcdef012345etcetcetc" ];
    then
        echo "Skipping GIT_COMMIT=${GIT_COMMIT}" >&2;
        skip_commit "$@";
    else
        git commit-tree "$@";
    fi
' --tag-name-filter cat -- --all

(Where abdcef012345abcdef012345etcetcetc was the ID of the commit I wanted to delete.)

Of course, you can make this cleverer to exclude multiple commits at a time, or run this several times, putting in the right commit ID each time.

What instructions should a computer support?

Derek Jones from The Shape of Code

The modern answer to what instructions should a computer support is: lots (e.g., many kinds of: add, subtract, compare, branch, load, store, etc). John von Neumann’s famous First Draft of a Report on the EDVAC, written in 1945, specifies 97 instructions (later, actual implementations contained fewer instructions) and modern Intel processors contain several thousand instructions.

The Turing machine has a very simple instruction set; the machine is driven by a lookup table that specifies one or more of the operations: erase/write a symbol (to the cell currently under the read/write head), move the read/write head left or right (on a tape containing cells), and load a new state (which may be the same as the current one).

When computers were new, the lure of creating a minimalist instruction set had theoretical and practical appeal (valve computers were large and unreliable, reducing the number of components improved reliability and reduced costs).

The design of the IAS machine, built in the late 1940s, was based on von Neumann’s design. Haskell Curry came up with a minimalist set of four instructions that could be used to implement its supported instructions (the idea was that programs would be stored in minimalist form to reduce storage overheads).

Minimalist instruction sets still have theoretical appeal.

Simplicity (rather than minimalism) became fashionable in the 1980s with RISC. This was a reaction to the implementation/runtime costs of very complicated of instructions found in DEC’s VAX and later Motorola’s 68000 processors. Supporting these complicated instructions generated additional overhead for the simpler instructions (which is what most programs spent most of their time executing). The idea behind RISC was that simplifying the instruction set would reduce cpu design costs, improve performance (by making simple instructions fast); leaving the complicated stuff to be supported via software.

Starting out with ‘simple’ MIPS, RISC cpus got successively more complicated with SPARC, Motorola’s MC88000 and then IBM’s RS/6000. I worked on code generators for the SPARC and MC88000 and found them somewhat dull after working on CISC processors. There were huge arguments around RISC vs. CISC (I suspect that many of those involved had never used a RISC processor), but then this was back in the days when many programmers knew a lot of the technical details about the processors they used. (How many of today’s programmers can name the Intel x86 registers?)

More background on 1950s minimalism in the paper: Less is more in the Fifties. Encounters between Logical Minimalism and Computer Design during the 1950s.

These days people are inventing very different architectures within which existing instructions have to operate, rather than radically new instructions.

The After Strife – a.k.

a.k. from thus spake a.k.

As well as required arithmetic operations, such as addition, subtraction, multiplication and division, the IEEE 754 floating point standard has a number of recommended functions. For example finite determines whether its argument is neither infinite nor NaN and isnan determines whether its argument is NaN; behaviours that shouldn't be particularly surprising since they're more or less equivalent to JavaScript's isFinite and isNaN functions respectively.
One recommended function that JavaScript does not provide, and which I should like to add to the ak library, is nextafter which returns the first representable floating point number after its first argument in the direction towards its second.

Outsourcing banana skins: Warning signs that your supplier isn’t as good as they claim

Allan Kelly from Allan Kelly Associates

iStock-500539718m-2018-02-1-11-06.jpg

So you think you want to contract out some development work? – yes, you know this area is full of banana skins to slip on, and you know others have problems but you still want to do it.

And you want to contract it out to an “Agile” development shop?

There are no laws against opening a development shop – a digital agency, an outsourcer, a consultancy, call it what you like. That is the beauty of capitalism, it allows pluralism. The hard part is choosing one that is competent, some outsourcers are pretty awful.

Everyone who can spell “Agile” can claim to be Agile, and most hire a copywriter to give them an online spin so they all end up making the same claims.

Those who are half good can coach their staff in what to say. And in truth, most of them genuinely want to do the best possible job for you – and be agile too. But how can you really tell?

Well… when I’m being cynical I think you can’t. The only way to really tell is to give them some work and see what happens. Of course once you’ve engaged someone you need to be both legally and mentally prepared to walk away.

So to help you here are some warning signs that you have stepped on a banana skin and your supplier isn’t as good as you – and they – want to be. You might even say these are warning signs that they aren’t really Agile.

1) Customer involvement

They don’t want customer involvement. They don’t want your people on site. They claim that your people get in the way. They want to be left alone to do things.

Obviously I’m thinking primarily of actual Customers, Users, Product Owners, Business Analysts and so on. These people should be working closely with the suppliers people. They should have direct contact, they should be discussing stories.

If your supplier isn’t embracing your people and treating them as their own team members something is probably wrong.

The supplier should be challenging your people – after all the suppliers are the experts, if they are simply accepting everything you ask for then something is wrong.

The same is true of other people you might want involved: a consultant or Agile coach should be welcome too. And if you decide to ask a third party to inspect their development then they should be open to this too.

Naturally they should also be open about the code too. After all the code will be yours one day.

2) Regular demonstrations

The supplier should be providing regular demonstrations – “show and tell” – as a very minimum. Every couple of weeks I expect the supplier to show the latest work. You – and your people – should be able to see working software offering more than the previous demo.

If the supplier is NOT providing regular demonstrations then you should be worried. Likewise, if the demonstrations don’t show progress get worried. Most of all, if the supplier doesn’t want to talk about why demonstrations aren’t happening, or how they can show progress then something is wrong.

3) Release, release, release

Show and tell demonstrations are good but the real test is to release to live. Releasing all the way to your live system. You might hide it on an obscure URL that nobody knows, or call it a beta release or something, I don’t care, the closer they can get to real live the better.

You supplier should be releasing to a live environment – or an exact copy – very very regularly.

The longer the supplier goes without an actual release the more nervous you should be. Sure, once in a while things go wrong and nobody is perfect. They may go two weeks with nothing to show for it. I don’t like it – and neither should you – but an occasional gap is OK.

Going four weeks without a release… I suppose it might happen in the early stages of the work. But it is in the early stages that you most need reassurance that they can deliver something – anything!

Six weeks with no release… well here we are into “3 Strikes and you are out.” Sure they will be able to give technical reasons why things messed up three times in a row. But take it from me, something is wrong.

The longer they go without an actual release to more concerned you should be and the more you should offer to work with them to address the issue.

Eight weeks? – eject, eject, eject.

4) Show me the tests

Maybe this should be warning sign #1 but for this you need someone technical, someone who knows what a test looks like. In the show-and-tells your supplier should be able to show you automated tests executing. Not very exciting perhaps and certainly not meaningful to the business but if they can’t show you then how do you know they even exist?

And if your supplier doesn’t have an automated test suite then it is certainly time to get out.

Ultimately the system they are building is yours. Your people will need to maintain it, or you will need to pay someone else to maintain it. Without automated tests that is going to be hard. Skipping tests now might make it look like you are saving money but you are not, even in the short term the lack of tests will bite you hard, it will push up costs and destroy schedules.

5) “Feature complete”

The phrase alone should be a warning sign. Equally the words “75% feature complete” (or any other percentage) is a big red flag.

If the supplier doesn’t have a test suite, if they can’t show working (preferably releasable) code then its probable they are feature stuffing. They will say they are making progress because “60% of features are done”. They may even start to claim they are feature complete but remember: a feature without a test isn’t done.

A feature without a test is pure risk. At any time a defect can put a hand up and say “Fix me!”

An automated test isn’t a guarantee of bug free code but without automated tests then I guarantee you have defects waiting to appear.

If you are in a relationship exhibiting any of these five sign then it is certainly time to talk. It may be time to end. But how do you avoid getting into that position?

Let me be as clear as I can: both you and your supplier should prioritise working, usable, functionality over more functionality. As the old saying goes “A bird in the hand is worth two in the bush”, working, deliverable (even better released) features are the priority, there should be less work in progress, fewer incomplete features, fewer “almost done” and as few as possible defects.

While cynical me thinks you might not be able to avoid it that doesn’t mean you shouldn’t try, so here are four warning signs that you are about to step on a banana skin:

1) “Agile is not that different”

Don’t let them tell you Agile isn’t different. In many ways it isn’t but if a supplier is trying to persuade you that you don’t need to change the way you work then it is a sign that either a) they don’t appreciate the magnitude of the change or b) they will tell you anything to get the contract signed.

Since you want a supplier who will challenge you it might not be a good idea to hire one who doesn’t like challenging you or doesn’t prepare you for difficulties.

2) “We are certified”

An extension of warning sign #1 is that the supplier is proud of how certified they are: ISO-9001, PMI, PRINCE-2, CMMI – some in the Agile world would regard these certifications as warning signs in their own right.

Scrum Master Certified, Agile Project Manager Certified, Scrum Product Owner Certified: these are slightly better but anyone who can’t tell you the flaws in all these certifications has myopia.

Question any organization that offers up badges rather than working products.

(Disclosure: for better or worse I hold a couple of Kanban certifications, while I think Lean Kanban University have done a better job than many in making their certifications meaningful I don’t think they are a panacea either. Anyway, Kanban certifications aren’t as recognised as those I just mentioned.)

3) Fixed or long term contract

IT suppliers have a long history of locking clients into “fixed contracts” – fixed scope, cost and time. These contracts are utterly flawed. Anyone claiming they can fix everything is a charlatan. Give them a copy of “Dear Customer: The Truth about IT” (the Xanpan prologue) and say goodbye.

Similarly locking yourself into a long term contract with a supplier before you have done some work with them is a bad sign. Do a small piece of work, for a small fee, with your potential supplier and see if they are as good as they say.

In my experience the best – most “agile” – digital suppliers can pick and choose their customers. If your supplier needs you more than you need them then it is a bad sign.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The post Outsourcing banana skins: Warning signs that your supplier isn’t as good as they claim appeared first on Allan Kelly Associates.