Showing posts with label practice. Show all posts
Showing posts with label practice. Show all posts

Sunday, 17 May 2020

By my But

I'm a little tired of my touch typing being out of practice, having been coding for a long time, I've let my actual narrative writing fall by the way side, and I've noticed a decline in the accuracy of my typing that must be addressed.

This will mean time, time writing, time throwing things on this blog perhaps!

However, the biggest problem at the moment is my fingers being asked to type the word "by" and I'm often caught out typing "but".

Which is very very annoying.

Friday, 13 January 2017

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.

Friday, 30 September 2016

Office Best Practices - Expenses & Purchasing System

After taking a stroll through these pages, you may tell that I once commanded quite a large IT budget, in quite a large company.  I worked throughout the UK, into North Africa and out across Eastern Europe with them... There were Four levels of expenses in that organisation:


  1. Capitol Expenses (> £10,000)
  2. Red Band Expenses (<£10,000)
  3. Blue Band Expenses (< £1,000)
  4. Green Band Expenses (< £50)

Each department had a cost code, and various levels of staff were able to order on various levels of expense.  This worked brilliantly, lets go through a couple of examples:

Billy in stores needs a new roll of tape for boxing up equipment, he gets out his Green Band expenses sheet, fills it out, hands it to accounts payable, whom check Billy can use Green Band, which he can, he is listed.  They pass the purchase order to purchasing, and the item arrives at Goods In, and is taken to Billy.

Perfect for small items, it lets routine business be carried out, without fuss, you have accountability, and you don't need a senior; highly paid; person taking time out of their day to check and sign every little order, there is a cap limit on an order, and only certain people are assigned the location, and there are two points at which these orders are checked & summed, accounts payable and purchasing.  If there is any "fiddling" going on, both those points can independently check the other, and both check poor old Billy is not getting a kick back on the company.

Purchasing can also try to seek the best price, and accounts payable can handle taxes and other considerations.  At any point these orders could be sent back, for example, one system I personally worked to implement was a link between accounts & purchasing to the stores database (a FoxPro database at the time - yeah, you remember that!!) and it let them query if anything they were about to order was in stock!  Simple, and for my time it saved the company about £8,500 a year in sundry purchases as we stopped being up to the ears in paper clips, biro's and printer paper!

The other various levels of expenses in this system did need other security measures, so on Blue band, which is where I started as a member of staff, you needed to get a managers signature.  There being three levels of managerial staffing:

  1. Managing Director/CEO
  2. Director
  3. Manager
Each manager had between six and thirty people working for them, each director had between two and five managers, and there was one guy at the top... Well one woman at times, to be honest, and she was better... Any how...

So, a blue band raised by me, went to my manager, then was ordered....

A, Red band, raised by me went to my manager or he raised it, went to a director and was  triple checked.  Very rare were these, so people often knew they were coming, and they were planned for and adhered to the strict budgets in the accounts department.  Us lowly minions ordering the stuff, we put out business case on the form, people knew what was being talked about, and so we knew what was happening, we knew whether someone was just lining their nest with kit, or whether there was a genuine business need.

And when this very business was in trouble and being bought out by a rival in the US, we saw these requests drop and drop, the budget fall and fall, it was easy to understand where the company stood, where everyone stood.  It aided transparency, which made the staff; even in the face of the company being taken over; feel assured there was a plan, and someone was in control.

Finally, a Capitol Expense, I only saw these twice, when I had to buy a company car contract for myself... I loved that Audi... And then when we actually purchased a building, yes a whole building.

They went to the top, were discussed a lot, and got the job done.

This layering, might today seem strange, but I bring it all up, as a history lesson.  This system worked, it wasn't perfect, but it was regulated, it was transparent, it was not based on whom liked whom, or who knew who, it was based on a form, going through a process and getting a result.

Exactly the sort of thing a computer is very good at, and all this today could forego the forms and be an online purchase request system for a company, you log on, you put green's straight through, you put blues to an assigned manager... etc.

So, why the history lesson?  Because today, I've sat for four hours, with not one but two broken HDMI to DVI leads, both my main lead and the spare were broken, and broken in the same way.  I suspect the spare had actually been taken by someone else and their faulty one left in it's place in my cabinet.  But whatever the reason, I had two faults, and two machines down and sat struggling without the target platforms I'm deploying to.

No-one else in the company had any cables of this type, they all generally just use VGA, I'm the exotic one with DVI and HDMI.

So I go to find my boss to ask for cables, I work directly for the Director of Technology, he's a busy man, he's an expensive man to employ I'm sure, so why should he take time out of his day not only to listen to my needing cables, but to carry out the ordering himself?

It beggars belief, he has to find the item he wants me to have, not the item I prefer or have identified, he picks what he wants me to have, he raises the purchase order and he places the order, letting accounts know later.  Then the item may, or may not, come straight to me, it may sit in goods in until I gee them along and ask where the cables are.  Or it may just get sent straight to the very busy Director himself and it'll sit until he has time in his very busy day to open it.

The net result?... Delays and confusion.  The system is a black box.  I believe the idea behind this is that ordering things is seen as an expense, and the ability to order something within the company is seen as a traditional expensive thing.  This maybe because this is a nearly 55 year old company, and they're stuck in very old fashioned attitudes.

There is no need for this cloak and dagger approach, security through obscurity may leave those at the top of the chain feeling secure, but it leaves those of us trying to get the job done stuff waiting.  During the time we sit waiting, I've pondered the risk to reward for the company...

Now, not wanting to let out how much I earn, but lets just say the costs of the items I've needed over the last fortnight would total about two hours of my paid working hours.  How many hours have I spent waiting, stuck, not able to work whilst the kit was ordered by one busy person?... Five.

This is not the "how long to wait for the delivery", this is not "how long to get purchasing to order them", this was just how many hours from my raising the request with the busy Director and his actioning looking for the items and then letting me know they'd been purchased; he in fact didn't let me know, so I just take the difference in time between the end of the first day and the next when I had the mail confirming the order CC'd to me.

Five hours, versus two hours, meaning, if the company accepted, developed or adopted a Green Band expenses policy like the one above, almost tantamount to what might have once been called "petty cash" then they'd save money.

But of course no-one is looking at this holistically, they look at the price of the item, the amount of cash you could be spending on ordering items, and they see a LARGE chunk of money.  The company credit could rack up a lot of items on an order, and they'd be accepted by the suppliers because we're in good standing; and I understand this, I understand the need to secure that process or ordering.  That security should be the responsibility of accounts and purchasing, not the Director of Technology, and not me.

For you see, as much as the cost of ordering items tallies up for the company, and the accounts show that easily, less easily expressed is the cost of an hours time on a salaried worker.  We are a fixed cost, and probably less than the total purchasing power of the whole company.  So it gets ignored as a non-cost.  To leave me sat here waiting costs nothing extra.

Of course however, it does, it leaves me wondering about topics like this, about how the process works, about why I'm locked out of this trivial ordering task; when I used to command huge budgets, why am I not trusted to order a cable now (and I've worked here for a very long time); and if I'm not trusted, am I considered expendable, am I considered a joke.

It's the simple self-analysis of Office Paranoia, and it all begins because of a lack of transparency in ordering, and a lack of forethought as to how much it costs to "risk" letting people order trivial, petty, items as opposed to having an expensively paid Director be comptroller of order slips.