Worst Idea in Development Ever

I'm casting back a long long way, over 15 years to be imprecise as I can, and talk about the worse idea in software development ever.... To perform a group code review once a week.

But before I can do that I need to talk about the good way to do this, code reviews should be non-intrusive for the majority of team members, they should be able to dip in and out, they should fit it into pieces of their day which are spare or otherwise dead time, and it should be use as a tool to not only review the code but introduce familiarity to other people's work & progress to everyone else.

So what was wrong 15 years ago?  Well, the important point about the good way of reviewing code was to actually be able to see the code.... When this new review process was introduced all those years ago... the code was on a machine, whilst we were all in a meeting room and the programmer stood up and verbally described the code to us.

Yes, verbally describing what took all WEEK to do, neither conveyed to us what was being done not shows us how, we were unable to help debug or sense check the logic, and it gave zero oversight into how the code was built, was it efficient for example (we'll come back to that topic in a moment).

And of course the planned one hour meeting was excruciating to be in... and only one developer got to speak in the first session.

There were 6 staff programmers and we were augmented with 6 contract programmers, the "lead" if you could call her that programmer went first... and her presentation was on the hardware to database connection.

It used a Marathon database, which I've just googled and humorously I can't find any references to that product.  And the "lead" had been using it at her prior role on Java based programming, here in C we were a little perplexed by her approach.

For she presented that from the high-speed buttons and lights on the hardware, which had to flash fast and had to be responsive to touch, she had written a system which took the impulses and inserted the values into a "Buttons" database table.  And then another on a loop which polled "SELECT * FROM LIGHTS;" and pushed the "on" or "off" states of the resulting list (from left to right) to the hardware.

Of course was immediately obvious to all but the lead, the manager and her office buddy, would not fly and the three different members of the team, all infinitely more familiar with the hardware and the C language than this lead, pointed out that it would be slow and unresponsive.   That we were on a single core machine so you couldn't just ignore that the database driver would wonder off and do it's own thing, as well as be constantly interrupted by the processing of our system, and the system itself was to be host to third party software which we could not ourselves fully control, so they might run with a tight loop starving our system and especially starving (what was then) a low priority database driver service.

All in all it sounded a REALLY bad idea.

But, she'd already done the work.  The manager had already signed off on her idea in a series of closed doors conferences with her, and her lone office buddy made it clear he was on side.

It was 3 staffers verses 3 "senior" staffers.

It was fact, this was going to happen.

Which brings us to an obvious fault in this "Code Review" no-one could actually get anything changed, we were really there to be told of the fabulous innovation from behind the green curtain.  We could not divert, advise nor simply appreciate the good, bad or ugly in this system.

So it was revision one (of twelve) was issued and immediately a real piece of content (a game) was played on the system... This game already worked on the old system we were replacing, so its behaviour was well established.  And immediately all the lights started to behave badly, they would he updating visually, we could see, from left to right... rather than all coming on together and going off together.

This was puzzling the micro-controller sending the light signals was a 32bit register, you just set the binary representation, and the micro almost immediately lit or extinguished the bulb... Why was it showing this left to right behaviour?

The three of us whom had descented said "are you going through that lights query as a list and applying it left to right?".... "No" came the reply, but she soon disappeared and came back with version 2.

Which STILL turned the lights on left to right, but subtly so, we could see it and the experienced play tested protested it was, but to the uninitiated it was just about passable.  So it went into test proper.

And they reported the same, but opposite feel to the buttons, that they lagged from right to left, and lag they did.

To her credit the "lead" didn't dismiss them and went to actually play the machine, yes she'd not played it until now... and immediately version 3 was issued.

Again, as with the lights, the lag was still there, the left hand most button was the most laggy, and that would make sense if there was a loop which was working through their being updated from right to left for the buttons and left to right for the lights.

But she insisted that there was no loop.

And we had no oversight on the code, even though we had "reviewed" it.

The next morning we walked into find her already present, version 4 had gone down to test.  The tester had put a different game on, which did a different series of light patterns and reported "It doesn't look right at all" (except he'd not been as polite) spurring the new version.

One of the more vocal of our group went to the manager and said "this going through a database is the madness, no matter what she's actually doing in the code, it can't be fast enough to feel like the old direct to hardware system, we need to remove this layer and just go direct".... but the manager didn't want to upset the "lead" so persisted with the database thing.

Release 5, 6 and 7 went down later that day, then about lunch a machine was hoisted up the fire escape stairs and into the office wheeled all the way and plonked next to the lead, she was to debug this properly.

Release 8, 9 ad 10 went only to this machine next to her and the tester was duly dragged up and into the room to sit, painfully, next to her explaining how it should plan and indeed he insisted the old system be wheeled up and plonked right next to the new borked on.

The two boxes side by side it was immediately obvious the new database driven system was really Really REALLY slow compared to the old one.

"It's the database" voices said.

"It's the loop" others called out.

"There is no loop, and the database is fast!" She persisted.

None of us from the C side bought this, and still could not see the code (code revision control is a topic for another day).

Finally, it was Friday, version 10 had remained for all of Thursday, but Friday came and something had to be done.  The engineer responsible for the board, the actual micro-controller was brought in, and he immediately ran his test routine on the board showing the lagging and we saw it being solid behave correctly and work, despite the lass having decried her board was faulty.

The hardware engineer had a view none of us got, he could see the code, he sat beside her and with us all gathered around he blinked, looked at each of us and then looked at the code, then turned to the "lead" and said "you know you can just sent the unsigned 32 bit integer directly to that register, all in one go?"

She looked at him and asked what he meant.

"Well if you want to turn it all on, send zero"... if you want to turn them all on send 4,294,967,295‬"

She blinked and looked at the code and then back at him, "I don't follow".

The hardware engineer looked at all our eager faces, three of us knew what was coming.

"Well, you don't need to loop through each boolean and bit shift them one at a time into your register sending them one at a time, you can still loop and bit shift them all in if you like, but you can sent the command once, set the lights to the value in the register once".

Three of us left the room, the manager looked dumbfounded and a little thunder struck, her office pal was notably quiet.

Version 11 came out about an hour later and the hardware engineer went to leave, popping his head into the office of the 3 of us on the C side... "Why wasn't this picked up in review?"

* Throughout you've seen me put "lead" in air quotes, this is intentional, the lass was not a lead, not as we'd describe today, she was just the loudest voice in the split office, she was furthest from the manager and had this knack of making you feel like she had ALWAYS been there and always been in charge.

I strongly believed she had been at the company for years when I started.

It wasn't until years later that I discovered she had only been in her role two weeks longer than me, two weeks in which she had moved from direct hardware peek & poke to via database.

* Version 12 : Yes you guessed it, version 12 was to remove the database from the hardware interactions completely, an abstract layer was built holding a representation of the hardware in memory and that representation was twiddled from the database side and it's representation imposed on the hardware by directly poking.

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 : Coding Style Clash

I've spoken on these pages before, and even shown, that I generally code to a standard, one of the rules I have it NOT to use Hungarian notation, but to use a notation telling me the scope of a variable, and then give it a meaningful name.

Now, over the last few weeks I've been involved in a new piece of coding with a group of like-minded individuals.  And what getter way to explain this oxymoron than through our coding standards.

Now, I like to use "m_" for member, lots of people can accept this, I like "p_" for parameters, a lesser few reject this than you'd think and some people even quite like this as they suddenly get to reuse their useful meaningful names, and in languages like Python they suddenly get to distinguish between locals, globals and parameters really easily... But then the controvertial one, the one which causes me most angst.

Locals being represented with "l_"... You might say the lower case "L" is asking for trouble, and I would agree, but I'm sticking with "l_" locals, and so did lots of other folks, however... I said we're a group of like-minded individuals... So not a group at all.

And so locals caused a bit of a flare up, because another chap had simultaneously, and without any prompting of mine, also come to the conclusion to use this same naming convension, however with one difference... He didn't call locals locals, he called locals instances, and so he used "i_".

Yes, that was it, the whole difference... "l_" to "i_"....

I could live with this, and when coming to look at his code I could read it perfectly well, and I was more than able to leave it alone, he however, could not, and indeed would not, leave mine alone.  He went so far as to write a script which line by line, looked for "l_" and replaced it with "i_" whenever he pulled from the remote branches.

He then proceeded to commit this massive change, the result... His one liner alteration was lost in a swamp of about 35,000 changes in his check-in.  Making his contributions near impossible to track.  I asked him to keep this just to his branches, and to stick to the "l_" for the master or pushes he tagged for merging, but he simply would not listen, he changed every "l_" to "i_".

Trivial things like:

std::mutex m_TheLock;

void Somefunction()

{

    std::lock_guard<std::mutex> l_LocalLock(m_TheLock);

}

Became:

std::mutex m_TheLock;

void Somefunction()

{

    std::lock_guard<std::mutex> i_LocalLock(m_TheLock);

}

And the change logs got longer and longer, the tracking of bugs became harder and harder, until I decided to pull my support of the project, and this is important, not because it looked like a hissy-fit on my part.

But it demonstrated to me something fundamental about the project, I happily bent to others, I let them name and title things, I didn't fix their code, only stuck to my own, I published my coding standard and people started to adopt it within the group, but I never forced it upon them.  Yet this one chap wanted to import and force his will through this tiny insignificant thing.

So, always, no matter your personal feeling, stay flexible, don't be that guy who insists on something for zero gain (or in this case much loss).

[Foot note: If your project/group/team has a manager, a leader, and is not a collective as the above, please disregard this, have a coding standard, make it clear, efficient and update it regularly, but have ONE person enforce it, don't let two tribes go to war over "i_"].

Development : Microsoft Tools Troll the Office

Today, I've been working on a brand new project, which literally I thought was parked just yesterday... My mistake it seems this project was expected to be being worked on.. A coworker is currently slogging through the same API but for a different (embedded platform) and it's taken him quite a while.

So the product owner for this new piece of software from me (which is to call XML Web Services through SOAP up stream and a hardware device over USB or serial down stream) was quite upset when they arrived at my desk and asked how their product was coming, and my reply was "Doesn't exists, waiting for the hardware".

After a short, and shirty, moment with them I assured them I would do all I could with the interface, implement ALL the XML Web Service calls through the published ASMX tomorrow... Which is today... They looked sceptical, gave me that long stare saying "no, no you won't"....

And of course I have!... Microsoft Visual Studio Troll tool award of the day, it is so simple to work with a published ASMX, just add a service reference to the URL and it generated everything for you, then tell C# you're using that name space and voila there it all is laid out for you on a platter.

I just finished this project, less than 5 hours after starting it, so have dished it back to the product owner to find the hardware, I know they're not going to believe how quickly I've completed this cycle on the development, not least because the other chap has been on it weeks and has only done about 60% of the calls so far... Yeah, I say... But he's not using troll Tools.

Sometimes, times like this in fact, I quite like C#... Don't let on, it's my dirty secret.

IT Sexism : What is Modern Development (for a Woman)?

Recently, I was challenged, almost to a fault, to enthuse myself about "modern development"... The quiz master expected me to extol about the virtues of distributed code verses centralised, to effervesce about sprints, about round tabling, about all these other buzz words and cockeyed concepts.

I simple asked the quiz master, quite what they meant by "modern development" ...

So surprised were they that they broke through a little bit of their shell and just talked to me, it was a refreshing change, moving away from methods and procedure, we talked about the system itself, avoiding even the language they were working in.

It soon became apparent we both worked from the same hymn sheet, just perhaps mine is an older copy... For you see, to me a good development job, doesn't necessarily sit with the work at hand, it sits with how you are allowed to approach that work, if you are just bombarded with red-tape and requirements and  micromanagement, then the person micromanaging you may as well just do the job on their own; and I have worked as the poor soul doing the work in just such a situation.  And it soon became clear this was the problem with the team this person was controlling.

It appeared they had gone through personality, philosophy and finally technical clashes, to the point that the four developers on the team didn't do much more than talk to one another about computers and draw their cheque each month.

The manager was doing all the work, not because she wanted to, not because she was female and they pushed it onto her, but because she had set high standards and promised delivery, but was getting no input from those below her.

In a paradoxical, and pretty toxic, situation, she was enabled to hire one more head, but not able to fire the useless four... She had ideas I might be that fifth chair, not a thought I relished as the conversation expanded into the actual problems she faced.

Now I've run into dysfunctional teams, but I know in the end the work either gets done or you all get fired, sometimes both.  But to sit and provocatively do nothing in the manner these folks did was tantamount to embezzlement, when I was introduced to them, they just sniffed and looked at me; I was egging myself onto ask them technical questions, but I was whisked into a private meeting room where this sad talk unfolds from.

After twenty minutes lamenting the problems I asked "What do you use as a way to leverage the work, what is that pedal you press to put on the pressure or get results?"...

She looked at me rather blankly, almost as though I were a magician showing a dog a card trick, as her eyes blinked she started to reel of a bunch of methods... Waterfall this and sprint that, and engagement in progress... yadda yadda yadda....

I put my hand palm up and asked again "not what procedures, what do you physically do?"

She didn't do anything, she sat in her office away from them all day and did code.  She never got out her chair and challenged them, she never spoke to then, she never pushed them in person... "Why not?"

And I was flabbergast to hear an intelligent, clearly able, mid twenty something, graduate and clearly decent programmer trying to manage a team say to me... "Because I'm a woman, they don't listen".

She was serious too!  Going on to explain that when she started she worked for a chap about my age, and they listened to him, she was one of them, but took a lot of ribbing, she moved into the supervisory role, still in the same room as them without issue, then was appointed to manage this new project when the other chap left... And that's where the problem started.

I wasn't sure whether it was green eyed envy at her progressing above them, or just because she had boobs, but whatever the reason I thought it extremely uncomfortable.  I saw her wanting, desperately to have a puppet in a more senior position to the team, to invoke her will upon them, and wanted myself (clearly 10 years older than them, and twenty something years her senior in age) just as a sort of enforcer and inquisition.

And I thought, her idea was "modern development", lots of buzz words and concepts, she had lost the "just talk to people" vibe.  Sadly because she was being intimidated, perhaps even sexually harassed... That, was the sad state, I found modern development in... Sickening and not a place I wanted to involve myself.

Programming : SDL_Window* into std::shared_ptr

I've had a little bit of a brain fart this morning, so to save you all the trouble, I'll go through it... First of all, I am working on an isolated system, therefore I had no internet, no clues, and importantly no books... This is a drag, because mainly I'll check things out look things up and just make sure I get things right... When things go wrong.

Unfortunately, things went wrong, and it was very early (for me) and I was unable to see the problem.

extern "C"

{

    #include <SDL.h>

}

SDL_Window* theWindow = SDL_CreateWindow (

    "The Window Title,

    SDL_WINDOWPOS_UNDEFINED,

    SDL_WINDOWPOS_UNDEFINED,

    800,

    600,

    SDL_WINDOW_SHOWN);

This code will create an SDL window at a unspecified location, with a size of 800x600 and the imaginative title "The Window Title".

This is fine, however, I hate seeing raw pointers, that "theWindow" variable irks me, it's just wrong to see that in modern C++ code; even if I am using a C based library.

So, I wanted to set about wrapping that into a smart pointer:

#include <memory>

namespace Xelous

{

    using SDLWindowPtr = std::shared_ptr<SDL_Window>;

}

This is my wanted type, "SDLWindowPtr", I know what this means to me, and I wanted to have a creating function wrap this for me:

The trouble?... This is considered an incomplete type, when we pass "SDL_CreateWindow" to the smart pointer ctor, it reports "incomplete type".

You can see the full error above, click to zoom in on the image.

So, what have I done wrong?... Well, the brain fart is to forget that "SDL_Window*" does not contain a standard destructor, it actually needs to be passed to SDL_DestroyWindow to close it down & release all resources.

I had totally forgotten this detail, I was too focussing too much upon the creation step and not thinking about the window objects life cycle.  The result was about 20 minutes wasted time banding my head wondering why this was happening.

Two cups of coffee and a pint of water, plus a wander down the corridor later, and I had that moment of realisation about this.

And so my code evolved, giving the solution to create a nullptr smart pointer result, then reset it to use the newly created window and instruct the smart pointer to use the SDL_DestroyWindow call for the clean up.

The complete code for a user might be more like this:

#include <string>

#include <memory>

extern "C"

{

    #include <SDL.h>

}

using SDLWindowPtr = std::shared_ptr<SDL_Window>;

SDLWindowPtr CreateWindowPtr (

    const std::string& p_Title,

    const unsigned int& p_X,

    const unsigned int& p_Y,

    const unsigned int& p_Width,

    const unsigned int& p_Height)

{

    auto l_result = SDLWindowPtr(nullptr);

    l_result.reset (

        SDL_CreateWindow(

            p_Title.c_str(),

            p_X,

            p_Y,

            p_Width,

            p_Height,

            SDL_WINDOW_SHOWN),

        SDL_DestroyWindow);

    return l_result;

}

int main ()

{

    SDLWindowPtr theWindow = CreateWindowPtr(

        "Hello World",

        10,

        10,

        800,

        600);

    SDL_Delay(5000);

}

We don't need to remember to SDL_DestroyWindow, we don't need to worry about forgetting to clean up, the smart pointer will do it for us when the reference count drops to zero.

Selling Infrastructure Today, to the Mindset of Yesteryear (IT Provisioning Talk)

Today, I'm going to talk about presenting, or selling, an idea to internal management.  How to sell them the idea of a capitol level expense without having it rejected.  Because in 16 years of professional development, I've seen the world change, when I began working the age of the Internet was in full swing, the dot COM boom was about to burst, but in infrastructure the world had two sides of a divide, "big iron", with big costs or PC's which were relatively cheaper.   Today however, that same PC class hardware (though in a different form - the wrack mounted server) is ubiquitous in the work place, however the costs for major infrastructure are ever growing.  To sell a purchase is a challenge, and this is how I've dealt with that challenge, and would like to continue to challenge it in my office today - if only I were given chance to help.

If you work in an environment where those above understand the value added to a business by having decent infrastructure, then you need not read any further nor know anything more than I envy you!

In a large business, or situation where funds and a core understanding for the need to invest in your IT infrastructure is understood, it is very easy to justify and secure funding for the right storage solutions to suit the business needs, be that a decent Network Attached Storage solution in a small office, or a large scale Storage Attached Network at the capitol expense level.  The key to getting either end of that scale of investment is not really explaining the hardware & what it does, though that is very important, but instead it is communicating multiple smaller pieces of the over-all jigsaw as to how this investment will impact and improve the company.

One can cherry pick topics, or even name drop them, "total cost of ownership (TCO)", "return on investment (ROI)", you can demonstrate the value of IT, the value of this hardware investment to justify the cost, and how integrating it with the business will potentially improve performance.

Anyone whom has tried to explain this the lay man, or just a stubborn audience, can find themselves on the loosing end of the battle, even with added credibility (such as your being ITIL certified), if your audience doesn't understand, nor buy into your vision of the future, or even if they're the kind of work collegue who likes to see the world burn, then you are going to struggle to put your point across.

This is something I wish to discuss with you today, for it's something which dogs the infrastructure around me, both professionally and personally.

We all understand that spending money today is hard, but those of us looking at what needs buying, sometimes we do know more than those who just look at the bottom line cost.  So seeing the price of new equipment as a cost, rather than an investment is the first hurdle to cross.

Before any jargon, before any numbers go on spreadsheets or slide shows, you need to set the mind of your audience into the correct frame, and this needs careful phraseology from yourself, and careful use of easy to handle concepts.  A practical example is also of good use.

Always when approaching this topic, I begin by never speaking of costs, or expense, I always talk about investment and better yet expansion.  Sometimes you may want to create a whole new system, such as a Storage Attached Network, this maybe many thousands of pounds, and if your audience has no idea what a storage attached network is your task is made more difficult.  So, immediately drop any technojargon, a none-technnical audience is going to feel more at ease with simple phrases and careful handling.

Introduce the technology later in your presentation, but initially talk about Storage over the network, or storage over the wire, talk about internetworking the machines in your company and a pool of storage.  Then explain the pool is to be stored on equipment known as a Storage Attached Network Array.

This jogging with the facts, and altering the terminology thrown out makes you appear less as though you are educating, rather you are introducing old thinkers to something new, and doing it gently.  All this introduction should take two to three minutes, no more, and have a big picture.

The best case scenario you can assume occurring is that they simply are looking at the price, the worst is that they think they know what you're talking about and that they know how much it should cost, by abating their feeling antagonised by your testing their knowledg with techno-jargon, you immediately stop their feeling alien from presentation.

Plus, they will one-day be one of the users of your new infrastructure, to include that, and the benefits of going the extra mile now in the implementation will improve their working environment for three, five, maybe ten years is worth keeping in their minds eye.

Once you have explained to them what is the target of your investment, you need to quickly give them a price break down, I recommend starting with the solution you want, it's cost, and a maximum of three bullet points about why... For example:

SAN unit, twelve disks, giving all the storage we need:

* Easy maintenance

* Brilliant Performance

* 3 years vendor provided assistance & service

Don't yet put the price, next give the maximum price example, and make sure you include the price as a negative, so they become aware you have checked above the realistic price point for a good solution...

Gold plated magnetic frizbee

* Again Easy Maintenance

* Best in class performance

* Most expensive solution

State boldy, this most expensive solution has no benefit over the previous mid-priced example... Remember you're trying to sell the idea more than the hardware, you're the buyer of this equipment, and you will be using it to furnish IT Service to the audience you are now addressing, they must realise they can pay more for something better, even if you do not want this top of the range performance and costs.

Finally, you should give a lowest spec variant, this should however, still be something you can manage, but do point out the added costs of your having to be there to trouble shoot, to coax it along, to keep it on the straight and narrow.  In todays world we do run a multi-facetted high availability model of computing.  Unfortunately in many middle of the road businesses the funds come from staff who's experience and idea of large scale computing is just that, large!  They remember the era of Big Iron of mainframes, they do not understand why a 1U sized server should cost multiple thousands of pounds, and they don't care for you explaining it.

But they do care that you show due dilligence in researching the costs of these items, and what you want to sell them is the idea that they are picking your best option.  So make sure there are more negative points with the least performant option...

Stone Tables

* Extremely slow to store data

* Difficult to source new media for

* Will require constant monitoring by staff to operate

The next piece of your presentation should focus on the price, but still avoid calling it a cost, a price is the "price of success", or the "price to deliver", never ever call is the "cost of ownership" or the "cost to the business", I believe this is the most erroneous part of courses such as the ITIL qualification; and yes I understand you need to explain the "cost" to a business of their IT services, but calling them a cost when you are trying to get investment in them from those above is ludicrous, address the costs of running later, today talk about the price, get the price out there as simple as possible.

A table is a good solution, the options you present in the order presented left to right, with your preferred column highlighted a slight different colour.

Include yearly maintenance, hardware maintenance, licensing & your estimated costs in salary terms, don't be specific with that last item, just let them know:

SAN Frizzbee Tablets

Capitol Investment £8,500 £11,850 £2,300

Maintenance/year £250 £530 £1,200

Additional* £500 £1,200 £2,400

Staff Overhead** £2,400 £3,800 £4,500

* One off costs related to installation or delivery

** Annual cost, estimated against staff time & pay grades, to operate the system in house.

Make it clear that you are presenting the best solution for not only the performance of the services being provisioned, but also in your own time, you are trying to make sure you are free to help the business expand.

The maintenance/year costs is also an area you should leverage, make it clear to the audience that you want to provide a continual improvement program, include that value here, and call it a value, never a cost.  This is one of the good clear items within the ITIL concept, that you have a continual cycle of improvement, if you never factor that into the cost of modern infrastructure, then you are as guilty of living in the past as those member of your audience stuck on the idea of "big iron".

To conclude your presentation, recommend your desired solution, explain you have gone both above and below the price point selected, and state this is the best solution for the business, make reference to specific things within your business process; and if you find yourself wondering what the business process is, then scrub your talk, you are not ready to deal with any queries regarding the business yet!

So, why am I talking about this?... Well, this is a problem relayed to me second hand from the office, there's a current effort to upgrade the whole network.  The server infrastucture has already been done, without my input, however, the next item is all about the network which is very much in my sphere of interest.

There are highspeed, high availability SAN's available on this network, however the back-bone is a mix of gigabit and megabit unmanaged switches, there is no separation of departments with VLans, there is a domain which I believe needs rebuilding as it sometimes struggles and there is a lot of network chatter all the time, from myriad devices.

All problems which could be solved with decent wiring and decent switching equipment, managed smart switches being one of the key infrastructure requirements... Are we getting decent switching equipment?... Unfortunately not.  And the poor soul who had to try and fight this good presentation fight, and whom lost, was simply beaten down in their request by old-hat thinking, indeed the quoted reply when they asked for managed versus unmanaged switches was "They all do the same bloody thing".

A bloody minded reply which pretty much set the tone of what was being delivered, for this being perhaps only the third major network infrasturcture investment in 53 years it's extremely disheartening to see the investment only going as far as replacing like-for-like, instead of actually leveraging value for the investment.

Is going from a mix of unmanaged switches going to solve all the problems in the business, no.  Is it going to solve some of them some of the time, yes, but only with lots of staff input still.  Would fully managed switches been worth the investment?  Yes!  Would they have saved on staff over head and solved more of the business challenges at hand?... Yes.

Unfortunately, and ultimately, the presenter of the idea was not talking to an audience whom were on the side of the technology, nor an audience willing to buy equipment for seemingly its own sake.  The audience was hostile, they were firmly of the belief that the problems would best be solved by working around them with a human, rather than with better equipment.

How do you argue against mind-sets like this?... Being qualified is one way, having qualifications to back up your argument is fine, but it only goes part of the way, and in my experience to go all the way with these arguments, you have to approach them in the manner we've talked about today, to bring the potentially hostile over to acceptance, and do it gently, do it by stroking their ego and making them feel part of the process, that they're really doing more than you ever will to benefit the company, by their accepting your advice, for the greater good.

21 Degrees: The Office Nirvana

There's drama in the office... And to be honest, I'm on the loosing end of it...

We've recently had lots of work done in our office, we've had new double glazed windows, which no longer allow fresh air, so then they added a new air system, which supposedly brings in ten cubic meters of fresh filtered outside air per person, but it's never on, you can really tell when it is, and it's great, but it's never on.  Then they added a very expensive set of air conditioners.

Now, I know, and you all probably know and office is not meant to be warm and cozy, if you want a place to sit and read or code which is very warm and comforting, try the local library; if it's not already shut through budget cuts.

No, your office is meant to be slightly cool to the feel, around 21 degree's I've always been lead to believe.  High ceilings are best, and if not, air condition to that temperature.

How do I know this?... Well, I used to be an office manager, and I managed the air conditioning, and I managed the people, all shapes, sizes, ages and sexes... The consensus was too warm and most people drop off late afternoon.

So, what's my problem here?  Well, I'm the latest arriving person on the flex, I always arrive around 9:30-10:00, which means I'm always the latest to leave, around 18:30-19:00.  The problem?  Everyone else in this area want the air conditioning warmer, the reason is they're all cold in the morning, they all wonder in around 7am, and disappear, leaving their phones ringing and desks empty around 15:30... This is a problem.

It's a dichotomy, because right now they're all moaning it's too cold, according to my desk thermometer (a hang over from being an office manager and worker for many years) says 21 (this is centigrade before anyone complains), and it's perfect.

The other folks around me are complaining they're cold, they're wearing jumpers, and cardigans and one chap has the biggest fleece on... They're all a lot older than me, yes at nearing forty I'm the young one, and I can't help but believe it's their age.

And, don't get me wrong, I understand they're cold, but they might need to get up and get moving, have a warm porridge breakfast, something, other than disturb the cool air situation.

Because when they've all gone home, and the sun is around this side of the building, through the un-opening double glazing, it's boiling at my desk, literally boiling.  And in this ridiculous circus I end up needing a desk fan on, because the temperature goes way up to 26+.

21 Degrees people, please, and you deal with it, I'm not the only one to know this.