The Worst (or maybe second worst) Source Control Ever

I've not made a bit deal out of this, but I like source control systems, I like git, I even like subversion, I like when folks even take the time to zip up the whole project tree and stick it on a whole other machine.  All are different source control strategies, each have their place.

What doesn't have a place in my opinion is poor implementations of this... such as... When there is no source control, that folks "remember" how the code was and can work back to where it was when things go wry.

Because inevitably they can't remember.  Solutions, subtly and satisfaction with what was present can easily be lost.  And in such situations you can only blame yourself for not having a back up of the original or yesterdays or whatever.

So it was as part of the tyrannical "lead" of one developer I came to meet the worst source control system ever, it was based on floppy disks, had no back up and was a manual process.

And it starts with an initial checkout, to a CD-R.

The CD-R was known as the "master" disc, and it contained a set of the SQL scripts to build an instance of the database, a series of sequential updates which each quarter were compacted down and made into one new "CREATE DATABASE/TABLE" thing.

Then there was an auxiliary folder with a bunch of tools which you copied to your hard drive and used.

And finally there was the source tree, you installed Microsoft Visual C++ 6 and opened the project and built the code.

You then ran a tool and put a floppy disk in, this disk was used as a swap between you and the lead developer at the end of the day, so a nightly build could be carried out (or a morning build on a Monday after a weekend) on a slightly more powerful machine.

As a developer then you had you IDE, this background tool running and you worked as you normally would.

Every time you would save in the IDE the tool saw the change in date of the source code file blatting that file onto the floppy.  The whole file, overwriting the old, not a delta, not a diffable solution, it just progressed forwards only.

You could not revert, not compare, not really do anything we take for granted in modern development.

This was a bad system.

The bad became worse when there was a delay between the save & the tool picking up, and then a floppy disk took time to write ( a lot of time ) and it was soon realized whilst it was writing the file from the HDD to the floppy it locked the file, so you couldn't write another copy of the file whilst this slow write was in progress.

As such lots of developers didn't run the tool, they would run it once at the end of the day, or just copy all the files listed as date/time changed to the floppy manually.

This floppy was then the feedback of all changes to the lead, in charge of merging the changes... Well I say merge, what happened was the mainline version was simply over written with whatever the developer handed over.  They were meant to qualify their code was coo, they were meant to run the tool which performed the copy.

So all the pieces were on the board and check-mate was one move away.

For the worst moment came on one particular Friday, a developer was toiling on tidy up duties, those little tasks you put off until the end of a day to fill time until you can go home, his task this day at 5:03pm was to correct two typo's in a file, one higher up and one lower down.

Just spelling mistakes, no need to recompile that, taking an hour, on a Friday with the pub and a takeaway calling.

So the chap performed his save, saw the light come on the disk and then did the second correction, hit save, the floppy light went off... and he turned his machine off... just dead off... pulled the floppy and dropping it into the "merge tray" on the leads desk started his weekend.

I walked into this on the Monday morning at 8am, as a very junior developer, the managers were all present, the lead was present, two senior devs were pawing over floppy disks in no discernible order.

For it turned out that the tool had started to overwrite the second save of the file, it had gotten so far through the write when the power had been pulled.  The original was lost on the developers machine for he had pulled the power... rather than shutting down.

And this source control system only went forwards, you could never ever regress.

The seniors were trying to build a delta list of each change for the last month, back to the start of the last CD-R... From floppies which had been used and reused, they had to manually inspect the changes between the file in question in the floppies.

If the copy they had was deemed to be older the disk was put aside.

If younger the file was copied into a directory to slowly try and catch the code up.

Around 10am the developer responsible wondered in, listened to the complaints, listened to everyone being exacerbated and then without a blink of irony said "Told you this wasn't source control".

Fabulous...

The worse Source Control ever?... Perforce... Hands down, Perforce.

When the Manager Went Fishing

A long time ago in a work group far away there was a bunch of problems coming up in a code base whilst the manager (who had written the very code we were debugging) was up to his knees in a Scottish stream on a salmon fishing holiday....

So yeah, the code didn't work, it was a statemachine implemented in a bunch of "if" statements a smattering of switch statements and flags which were not properly mutually exclusive... so it was a statemachine in name only really.

This particular piece of code was responsible for paying money out of a machine, and as such came under scrutiny when customers started to notice that it was either paying out more than expected or the players of the machine noticed it was paying far less than expected.  A double whammy.

This problem was looked at first by a chap in the team who didn't really get along with anyone else, and he asserted he had solved the problem... I wasn't his manager, but we accepted his word on the matter and issued a release.  This turned out to be the start of a series of problems, for with the focus on this problem the test department took it upon themselves to actually test this fault to within an inch of it's life, and of course they found the problem persisted.

The wheels then came off this development train.

For the technically senior person in the department didn't get on with the chap who had looked at this problem first, they did not get on at all... not one jot.

And I ended up sitting between these two as both a debugging sounding board but physical altercation deterrent, which it's a great place to stand between coworkers who really just needed to grow up.

The debugging progressed from the mess of code into a rewrite of one function, and this started with a large discussion around a 10 foot white board (I love working on a whiteboard).

We came up with the expected behaviour, worked out the inputs we knew and then how to get that expected output to physically happen, and did so.

It worked, it would have taken that one day.... The test department were happy with their results.

The problem?  All releases had to go through review and the binaries built and packaged by one specific person... The Manager... who was still scaring salmon with a pointed stick.

We had to get on the phone to him, do you know how patchy mobile reception is in the highlands?... No... Well, "VERY" is the best way to put it.  We managed to speak to him twice, but then had to get his permission at every step, "Do the work" it's done, "build the binary" it's built, "package the update" it's compressed, "create the release notary" it's written... 

All these calls back and forth to stitch together what should have been my simply putting the package on a flash stick and handing it to the test department (because they tested everything off of our network to be as real to our operating environment as possible).

It was a nightmare... An utter break down in co-worker communications between the other two chaps, the manager not releasing the reins of control*... The slow turn around of a build and messy nature of the codebase we had to edit... not to mention that the problem was subtle and caused by a miss-understanding between the true behaviour of a physical device compared to the expected virtual representation of it within the system's view.

There, that's what happens when the manager went fishing.

* In the hope of accruing himself come modicum of job security by appearing to be a key man.

My Three Lions 2018

Being English, specifically an avid supporter of English Football this week is extremely hard to bear, the hope, the wish, the fear the turbid mix on the street, wafting on the radio airwaves and in nearly every news report.

I love English football, the agony, the pleasure, that moment the wife storms out the room declaring "I'm stopping watching this" only to see here peeping around the door-frame thirty seconds later.

We love you England, we do.

And I find a tear in my eye whenever I think back to that warm summer of '96 as here in Nottingham we saw the Turkish team play at the City Ground and the hurt that followed.

I stand up to be counted.  I am English.  We are United.  We will play.  I hope they can win.

But whatever the weekend brings, we still have our Lions, three of them, proud and loud.

Hear Us Roar.

Introduction to C++ : Starting C++ Series Part 1

A few of you maybe aware of the book on Python I wrote, and published, last year?  And I've had at least one reader get in touch for a second part.  Unfortunately my gaze has passed over Python and returned to where I live.  The world of C++.

I have a particular problem with the C++ developers I'm meeting of late, they're either simply not C++ programmers, being an actual mix of good and bad C programmers or just not programmers at all (in one case).  Then even when they are very good C Programmers, there's been a mix of the up-take on ideas and feature benefits of modern C++ itself.

Its to and for these fair folk I have begun to write about C++, a new book, based on my own real experience but tempered with where I believe teams and individuals are going wrong when converting their skills to modern C++.

For the programmers reading here now, it starts with a chapter zero... Lets take a sneak-peek....

Chapter 0: Introducing C++

It is incredibly hard to introduce the C++ programming language without at least the most cursory glance at its direct predecessor C. C was created by Dennis Ritchie whilst at Bell Labs sometime between 1969 and 1973, in 1978 Dennis co-authored a book, the book, on the C Languages with Brian Kernighan. Together known as K&R, Kernighan and Richie's book was a great success,

spreading C into being, arguably, the most widely used programming language at the time, and still in that top ten league today.

The success of this first publication, its relative low price of entry into the fast developing world of C for an ever growing number of different machines, really did set C as the language to learn for a very long time.

"C has all the basic elements for expressing computation, it has iterations, it has data types, it has functions and that's it. It doesn't get into the game of expressing abstractions" - Bjarne Stroustrup.

So the world was until 1980, when a talented programmer by the name of Bjarne Stroustrup;  working just down the hall from Brian Kernighan at AT&T began a project. He called it "C with Classes". Intended as a natural extension to C, it inherited a large part of the C language syntax as well as many of the mannerisms of C and general purpose computing from the late 1970's.

The concept of "C with Classes" was to furnish users of C with a way to allow the representation of abstractions, if one wanted to represent a car in code they could define something called a "Car", it could have internal values to represent it's speed, direction of travel, the fuel level, everything that we think of as a car could be expressed within a class. In C one has no such way to encapsulate such functionality with any form of familiarity.

Certainly in C you can have a set of variables which represent the exact same things, you can name them to have a meaning of "fuel level", however they are not within anything known as a "Car" you as the programmer has to remember where all these values are, what they are called you have no easy of recall to get back to the values you are using, the concept of a class (what today we also call an object) was one of the major drivers behind the work being carried out.

The name however, "C with Classes" was not as succinct as one might desire, and indeed a friend of Stroustrup suggest he change the name of the language to C++, as the "++" function literally means to add one, an increment. The new language is an increment over the old.

Since then C++ has been ever evolving, in 1998 the first standard version of C++ was codified, from pre-existing attempts to unify the language by both specific vendors of tools for the language (such as Borland, Microsoft or Lattice) and industry bodies (such as ANSI). Published as ISO/IEC 14882:1998 by an ISO working group, C++98 drove home that C++ was at last truly diverged from C. A language in its own right, and something which had to be thought about differently.

I myself started to learn C++ in 1996, the difference in the community before the 1998 standard and afterwards was palpable, since then four other standard have been released. 2003 brought C++03, 2011 brought a working set of revisions ultimately called C++11, but also known as C++0x (due to the new standard taking so long to finalised, it was drafted and promised many times between 2004 and 2009 hence "0x). 2014 saw a further release as C++14, then 2017 saw C++17. The next revision is slated for 2020, it's name is yet to be decided, though good money could be placed on C++20.

From this release schedule we can see the acceleration curve, the faster and faster pace at which C++ has and is diverging from it's roots in C. It has matured, expanded and at each new update become more inclusive of functionality based on abstractions.

Today you can pick up modern C++ and it contains much more than the sum of its parts, you can express everything you could in 1978 in C, but so very much more.

Unfortunately, this success in expanding it's expressive nature, incorporating ever more abstractions and structures from computing, and every-day life, is tainted with some sadness, for as much as C++ strives and drives and builds every upwards, forever it has this seemingly unbreakable umbilical back to C.

You can pick up any C++ compiler from any vendor today, on pretty much any platform, and input a huge swathe of code written not in C++, but still written in C. You can elect to put this very book down right now, pick up a copy of the same book published by Kernigham and Richie in 1978 and produce code which works and work-ably solves some parts of the computational challenges you

face.

However, none of that code will be expressed in the powerful, elegant, I think beautifully powerful manner in which C++ allows you to. Abstraction, encapsulation, expressive representation of the real world in code in a manner which betters your understanding of the topic (as the programmer) but also allows others, non-programmers, to comprehend the devil within the detail of programming a modern computer.

Development : Scrum & Leveraging Virtualisation (My Hobby Team)

Recently in one of the Scrum teams I oversee as their Scrum Master, I saw a common problem, one or two members of the team were being blocked by mundane issues once or twice a week.  For one member of the team this was a physical PC fault, for the other it was disk-space.

They are running their own equipment, outside the remit of my authority or the company control, therefore I had to clear the decks in some manner, the solution?

Well, the development was all Linux, I created a standard Ubuntu image and issued it to all concerned and asked that these be the ONLY virtual machines run to complete work.

The first week of this resulted in a slow time, I found people were not using; as per the original specification; virtual machines at all, I found they had a mish-mash of development materials, and importantly nearly every person asked me to allow them rights to install software.

I didn't allow this, instead I used the Scrum management software I've put together and collected all their ideas about editors, tools and software to add to the image, and we had an additional 10 minute open discussion going around the group to assess the merits of each piece of software, what it would be used for and how it might leverage either an easier time to task completion route or how it might introduce potential benefits in other ways.

I started with the proposer of the software, then alternated between those in the group whom had indicated they liked the software option and those that had not, in cased where no-one objected to a piece of software, I simply took the concensus benefits and added them as points below each item listed.

In the end we had reduced the pile of suggestions to three, the first a lightweight text editor, many were split between "just using nano, pico or vi" and those "desparate to use sublime".  This came down to a simple choice, one was free, one was not, we have a sub-zero budget since having to source those drive caddys last month... Everyone was going to use my preference "nano".

The second was a performance measuring tool option, to monitor the system, I opted to leave this decision to the testers in the group they have yet to advocate a choice, but I decided to take the option out of the scrum teams scope of interest, their code has to be fast and that's the end of that discussion.

The third was an art package, there were many options, one person wanted to do all their art in Paint.NET on a windows machine then move it into the main project, another wanted to create assets with GIMP and another wanted to use Photoshop. on his Mac, an easy decision GIMP.  It's native to Linux and free.

The standards were set, we would use tar and gzip on the image I had issued, Nano, GIMP, Code::Blocks and the compiler was the GCC for the group.

For diskspace, problems, every individual member was issued a brand new 1TB drive, the Ubuntu Image and they had to host this virtual machine however they wanted, it needed a single CPU core and 1GB of RAM minimum.  Many of the developers were able to tweak and give the machine 4 cores and 4gb of RAM.

Since then the team has run a lot more smoothly, issues with your software, pull the VM image down again... Issues with the source tree?  Delete your local working copy and resync with the repo server!  Need a place holder image?  Fire up GIMP.

This was the first time, since the New Years, that I had reviewed the team in any depth, as a Scrum master in this situation I don't have a lot of blocking or shielding duty, individuals work in their own time and in their own homes, so they have to deliver or fall short.  It is a hobby project after all.

However, our first Sprint feedback is in from yesterday evening, the overwhelming feel is that the team is now working much more quickly, they are verging on out stripping all previous schedule expectations (which were secret from them) and yet they all feel this is easy gliding development time, moving from product point to product point without the hassle of their machine or not being sure how to run an item, or not having the same set up.

My next task?  To do the same with the tester group... What a bag of cats they might be....

Development : No Tests before a Prototype

I am NOT a fan of test driven development, does this mean there isn't a place for tests whilst you work?  No, it does not, I believe there is a place for tests whilst you are working, however that place is beyond the initial hard development and broad strokes of laying out the project.

When you first begin a new project there are so many things to consider, settings, scopes, layers, inherited domains just so much you need to physically take from the design pages through your teams brains and down to the keyboard.

I could even define this as a "pre-sprint" within Scrum to push out a product that the owner can then give you that first feedback on; especially if they are none technical and from this point on, from this first step you can cycle through Scrums into Sprints and with that change you can seed your development into more expansion and maintenance of code, when you do that, when you have something to test against then you need to add those tests and start to use them as a tool.

They should not drive your development, they should drive your keeping the developed work in order.  N-Crunch, N-Unit, G-Test... All these frameworks on certain languages (like C# and Java) work very well as you can reflect out the language, but before you can reflect out something with languages like C++ or C you are stuck over-engineering your tests before that first evolution of the project.

There is a name for this first evolution, it's called a Prototype.

Not many teams value a prototype, indeed Scrum itself never mentioned them, you are meant to jump from idea to stories to backlog to releasable code, and in my opinion this is not easy, it's not really communicative of what you are doing either, especially when the product owner is the only person within the development stack whom can redirect the team, but without that first tangible something many product owners can be literally lost.

Earlier this month I talked about the idea that a product owner needed to use the software life-cycle, an old idea, but a good one... Today I'm saying before you can really start to use inline tests within your IDE and before you can start to run scrums you need a prototype, arguably an even older development paradigm.

So what is my point?  Why do I keep bringing this kind of topic to the fore?  Well, simply put I believe there are far too many teams with far too many people in them not willing to push the envelop, whom are not willing to ask questions of the process they are following, not willing to bend or twist or shape the working environment to their way of working whilst simultaneously keeping up the bests practices those processes are there to enforce.

I suppose a Scrum Master should help with this process, but I find far few do, because the division of my problems with these Agile development mantra lie in the disjoint between idea and actually hitting the keys.  At times I see teams which are literally headless, they are a dozen monkeys typing a dozen keyboards, and they're being cheered on by the Scrum master, beyond those walls however they've no idea how it applies to the company, they have no interest or feedback on the return on investment that the Product Owner is all about.

A prototype, beyond a discussion, beyond the initial design, it can form the best kind of spring board and drive the best kind of Product Owner feedback down that chain, but it has to be created unfettered, unburdened by the micro-management of a scrum or sprint, it has to be created in a linear no-none-sense holistic head-space and used as a tool.

This is not being done very often in the teams I see around me.  Perhaps because it is thought of as old school, as a "has-been", however, if you look the hyper success of some products; say Minecraft; it maybe managed however Microsoft want now, it maybe teams running sprints, however Notch started it all with a Prototype.