Archive

Archive for the ‘Development’ Category

Resigned

March 22, 2012 Leave a comment

In March 2012, whilst searching for a new job following the disappointment of ABCD, I was introduced to a company local to me. Research and interviews followed, and my instincts screamed out at me that these guys knew what they were doing, they were technical from the ground up with a business advisor who was generally recognised as an expert in his field.

This post is not about them; it is possible that the above may be the last thing I write about them. This post is about leaving ABCD.

I knew that resigning from ABCD would be a harrowing experience. Not emotionally, no: but because four months into the job I still wasn’t sure who my line manager was and thus who would handle any HR issues. Details like these are normally spelt out in detail within terms of employment documents, but I had yet to receive mine; indeed, the only details of the job I did have in writing (either paper or email) were my salary, holiday entitlement and the hours I was expected to work.

Notice period? No, that’s not there. Under UK statute – and, rest assured, I even telephoned ACAS to confirm – the minimum notice period an employee is required to give is just one week if no other time period is given. I wanted out of the company, I was far from being an essential employee in my eyes, and the sooner I could leave the better. The only project I had outstanding had barely a day’s work left on it, so even on moral grounds there was no reason to worry: I’d be saving the company three weeks of paying a salary to someone who everyone would know didn’t want to be there.

I decided that one certain individual, who had been responsible for my recruitment, was the most likely candidate, and addressed my resignation letter to him giving a final date of a week and a half away, to round it off nicely on a Friday. The letter was signed, left on his desk, and opened at 11am the next morning to much surprise and a little consternation; I was warned that the MD may take the “one weeks notice” element quite badly.

Various conversations happened that day, including one with the MD which went surprisingly well. He countered the offer with a promise of an immediate 5% pay rise, slightly shorter working hours and a chance to move to an architectural role and oversee changes to the whole project management process in order to increase efficiency. Had these suggestions been made several months before they may have been of interest, but they were too late now and, having been given 24 hours to consider, I was called into a chat between him and another member of the management team.

The chat they were having was positive; indeed, I was singled out for praise over the work that I’d been doing that was directly influencing clients into buying into the company. It started going downhill quite quickly though; the following is paraphrased but based on notes made about 10 minutes after the events in question. “OP” is the other person in the meeting, who I don’t wish to identify even obliquely.

Me: “I have decided, and I will be going with the other company”
MD: “Ok, I think you’re making a really bad decision.”
OP: “So do I.”
MD: “I think you’re making a really bad choice and you’ll end up regretting it.”
Me: “Yes, but that’s my decision.”
MD: (sigh) “Ok, that’s your choice, but at least we’ve got you for four weeks.”
Me: “No, I’m on one week’s notice”

A slight pause …

MD: “No, you’re on four weeks notice. That’s standard.”
Me: “I haven’t had anything saying I was on four week’s notice, and statutory is one week.”
MD: “OP, what did the offer letter say?”
OP: “I’m sure it would have said notice period on it.”
Me: “It didn’t. I’ve checked.”

At this point, the MD stopped and simply stared at me. I suspect he was trying to get me to back down, but this was one of those moments where rights needed to be asserted and I would not have put myself in this position had I not been 100% certain of my legal position.

A second or two later, with neither of us giving an inch, he played the only card he had left.

MD: “That is low, and you are the lowest. Get out. Get out now. Go and clear your desk. OP, you will escort him out of the building.”

I sat, slightly shocked for a moment that he could turn so cold, and at such speed, then stood up and walked out. Neither the OP nor I talked whilst I cleared my desk and removed my books, and said a brief goodbye to those left behind. As we walked to my car, he tried to say something and I suggested – nicely, he was himself quite shocked – that we wait until we were out of both sight and sound of the office, to avoid him being seen to do anything to raise the MD’s ire even further.

I was glad to go home, to enjoy a bit of time with my family and to work on my house, knowing that the decision I had made had just been justified even more than I’d even suspected possible. The OP, who I now know to also be job hunting, had to return; resigned to the fact that his life was just that little bit more hellish than before.

Categories: Development

Maybe I was a bit hasty …

March 22, 2012 1 comment

In October 2011, I accepted a job at a company I previosly referred to as ABCD. I had a number of reasons for accepting the job, not least of which was that ABCD were in the business of selling software to “big business”, and as a result had a vast number of three- and four-letter initialisations with the odd acronym thrown in. As a move from a company whose business model and management I had ceased to believe in, it seemed like the ideal opportunity to add a few useful phrases to my otherwise “small business”-focussed CV.

Of course, dreams can sometimes turn into nightmares. Rather than the model of ruthless efficiency that I expected, I was shocked to discover the number of areas in which ABCD could have performed so much better. In my four months at ABCD little changed, and for reasons that will be explained in a later post if change does happen it will not be by my hand. A few typical examples:

Source Control

ABCD use Microsoft TFS, in itself not a minus point. Unfortunately, at the point of initial setup it was misconfigured such that to edit code a developer must branch from the “tested” tree back into “development”, update all the version numbers, change permissions, and then perform their edits. Once fully tested, code is then branched back into “tested” with a new version number and the “development” tree cleared again.

Project Structure

The entire system contains some 50 to 100 individual Visual Studio projects, some of which are merely business classes to support a single UI project. No solution files are used (due to the paths to the projects constantly changing), therefore a developer typically has 3 or 4 instances of Visual Studio running.

Project Management

All work is managed through a central bug database, where a developer is assigned a “bug number” to work on (whether it is for a bug or a new feature). Through daily timesheets, which are emailed to the management team, progress is updated until the work is ready for “unit testing” – a document written by the developers that runs through a few basic tests of functionality that is then uploaded into the bug database to indicate that system testing can commence.

I could easily write a dozen more points, but all of these are issues that are put up with. People faced with situations like this can generally be divided into three separate groups:

  • Those who are aware of the issues, and choose to do nothing;
  • Those who are aware of the issues, and try to change them; and,
  • Those who are unaware of the issues.

I try to be the second of these, however the most I feel I’ve been able to do is turn a few of the “unawares” into “aware but choose to do nothing”.

A company generally gives an employee three months to prove themselves before they are made a permanent member of staff. I’m a firm believer in the converse also being true: an employee should give an employer three months, in order to show that they are a company that the employee wishes to stay with. In my case, ABCD was sadly not a company I wished to stay with, and so in late February 2012 I updated my CV and returned to the agencies, cap in hand, hoping that mistakes such as this are lessons to be learnt from and not repeated.

Categories: Development

Why Microsoft.VisualBasic should be buried

December 6, 2011 Leave a comment

A friend of mine, who I hope won’t object to me recounting this anecdote, was recently posed the following interview question:

What would you change about the .NET framework?

To me, the answer was simple: I would deprecate the Microsoft.VisualBasic namespace with immediate effect, and phase it out entirely by the time version 5 of the framework was rolled out. It is a relic of a language that ceased to be ‘current’ 10 years ago, yet is still being actively used; even this week I have seen code, recently written to run under .net 3.5, actively using methods from it.

To understand the reason for it existing, it is worthwhile looking back to when .net was introduced. Microsoft was targetting two separate groups of developers: those coding in C or C++, for whom it developed C#, and those moving forward from Visual Basic 6. For this latter group, they included a number of VB6 commands, using them as wrappers around the .net equivalents; these were placed within the Microsoft.VisualBasic namespace, with it being automatically included as a referenced namespace in all new VB.net projects. As Microsoft go on to say in their page about Visual Basic .NET internals,

An important goal for Visual Basic .NET was to retain as much backward compatibility as possible, while providing more power and flexibility for the developer. This was accomplished by providing “helper” methods such as Rnd (which is a static method on an imported class) and intrinsic language features, such as CInt, to provide functionality identical to that of Visual Basic 6.

Unfortunately, not all VB6 developers embraced the object models available, and as a result far too many developers are still using the constructs such as CInt() as shortcuts to the .net equivalents. Those developers presumably assume that CInt(number) is equivalent to int32.parse(number) both in functionality. Nothing can be further from the truth; from the same page:

While there are a few specific methods that don’t provide the same performance characteristics as Visual Basic 6, you can fully expect that a Visual Basic .NET application will significantly outperform its Visual Basic 6 counterpart.

Our simple CInt() function performs a wide variety of options, covering parsing, boundary checking and rounding. Using it leads to inefficient code and, more importantly in my mind, developers who are unskilled in the wider concepts of OO within the framework.

Microsoft.VisualBasic is a relic, and deserves to be buried.

My Legacy

October 21, 2011 7 comments

In July 2004, I was offered a development job by a start-up firm I will refer to as ‘ABCD’. I was sorely tempted at the time, however ABCD were undergoing a round of funding at the time and they couldn’t guarantee when I could actually start.

In August 2004, I was offered another development job, this time by a three-year-old firm I will refer to as ‘Acme’. Acme had a small team of developers already, were offering me the same salary as ABCD, and would let me start work as soon as internal issues (relating to the individual I was succeeding) were resolved.

In September 2004, I took a job working for Acme. A Delphi-based software house, the managing director was astute enough to realise that they were blindly following a dead platform, and I was tasked with leading the company’s development forwards. Within a fortnight, all the developers were on a course to assist them with transitioning to VB.net, and my work had begun.

Since then, I pride myself on the way that I’ve pushed the development within the company forward:

  • The code was overhauled completely, migrating to VB.net where possible or providing (with a view to eventually ending) support for clients using existing Delphi software.
  • As each new version of Visual Studio was released, it was evaluated and software slowly migrated onto it for continuing support.
  • Where possible, applications were migrated to the latest version of the .NET framework itself, and to updated versions of SQL Server to take advantage of newer features.
  • Seeing the potential drop in support for VB.net both from Microsoft and the community in general, I started learning C# in my own time and within a week was easily able to convince the MD that, for the benefit of future recruitment and support, all new projects should be written in C#.
  • Spotted the advantages of object-based database models, and as soon as was viable dropped our database layer in favour of Microsoft’s own Entity Framework, giving us access to toolsets including LINQ.
  • Saw the ease in which MVC allowed the splitting up between development and user interface work, and (having rejected the original asp.net MVC and MVC2) evaluated then adopted MVC3 for all future work.
  • Kept track of best-practises, and whilst never dictating rigid development standards still ensured that all code would be written in a manner familiar to any other team member.
  • Continuously educated the ever-changing development team about key aspects such as software security and encryption.

A year ago, a new member of staff joined the company. Claiming to have prior experience in development, he assumed the role of project manager whilst claiming a job title giving him overall responsibility for IT and Operations. It is this individual that I refered to in my previous posts of the Security Moron.

Within a week, he had sent around his former employer’s Development Standards document with a recommendation that we adopt it; not only was this document related to his former employer’s business but it also explicitly ruled out processes and procedures that we had adopted and were actively using, whilst making further recommendations that were nonsensible in our type of business.

Since that time, his input into development, albeit not as a developer but as an operations manager, have increased as his failings as a project manager have became apparent. I have already documented his failings related to security, but when it comes to development he required that certain processes become self-contained modules of work, with little understanding of how these could work in practise or of the downsides associated with them.

His plans for a ‘central audit module’ bore no relation to reality and thus when one was implemented to his requirements it was so non-specific that any output required further work, whilst the ‘security module’ written to his specification actually managed to increase development time considerably and leave code significantly less maintainable that if we had done without.

The one project that he was placed in sole responsibility for from start to finish is generally regarded as a flop; well over budget and currently on the verge of cancellation due to incomplete requirements (that I had been assured many months ago were “100% complete”). Today, we have been given notice by a client that I personally have serviced since my first day that they were taking development in-house after a year of incompetent support under his care.

Furthermore, the company as a whole is following a business model that I specifically recommend against in my previous post ‘Unsupportable Success‘; the managing director is willing to take on any work involving a support contract with no consideration as to who provides the support or even the hours that the contract covers.

A month ago, I was approached by a recruitment agency; a client of theirs were hiring and I may be a good fit for a role they are filling. Persuing this further, it turned out that the client were none other than ABCD (although the agency were unaware of my previous contact, and ABCD themselves had changed so significantly that my offer was a documented, but otherwise unmemorable, blip in their past). The interview went well – so well that, half-way home I received a call from the agency asking me to turn around and return for a second interview that same evening.

As of yesterday, it is now public knowledge within Acme that I have accepted an offer from ABCD. Within an hour, I was excluded from the ‘development team strategy’ meeting, and from now on the development within the company will be pushed forward by the Security Moron.

I had hopes, one day, that when I left Acme I would leave some sort of legacy, in that someone else would take over and push the development team forward in the way I have: my team contains a number of people, each of whom could easily fulfill that role. It is a standing joke within the team that everything the Moron suggests is prefixed with ‘in my old company…’, and the weakness in his technical skills are obvious to all. But with him assuming charge of development, any change will be despite, rather than because, of him.

I no longer have faith that the company will progress. I no longer believe in Acme. I will miss the people here, but I will not miss the company.

Categories: Development Tags: , , , ,

Unsupportable Success

September 23, 2011 1 comment

In today’s business climate, a lot of companies struggle. Some have difficulty getting work in, others cannot recruit enough people with the relevant skills, whilst yet more have difficulty managing cash flows when clients withhold payment or decide on new terms of business at the drop of a hat.

But what isn’t realised is that a business can also suffer through being too successful, and not spotting that the work coming in now is going to lead to serious problems in the future. One type of business in particular is vulnerable to that: the software development consultancy.

In his essay “Ramen Profitable”, Paul Graham describes the difference between a “consultancy” and a “product company”:

Startups have to be product companies, in the sense of making a single thing that everyone uses. The defining quality of startups is that they grow fast, and consulting just can’t scale the way a product can.

http://www.paulgraham.com/ramenprofitable.html

It’s this scalability factor that is major problem, and is best described by example. A typical consultancy follows the following business model:

  • A new client (or, a new requirement from an existing client) is captured and goes into the sales pipeline.
  • Work then starts on that client’s project, which in a smaller organisation (to ensure that cash can flow) often takes between 2 and 3 months.
  • Following delivery, the project then enters an initial support phase, which the company puts time aside to manage.
  • Once that initial phase completes (say, one month after delivery) the consultancy pushes the client towards a support contract; this contract places requirements on the consultancy to fix issues in a timely manner but also guarantees a certian level of income to support future development projects.

A savvy start-up consultancy would take a handful of these projects on over the course of a year or two, to the level where the income is sufficient to cover another developer or two working on a “product”. The “product” then starts making its own money, and the focus shifts to supporting this single product. This product can then be sold to clients many times over, with a proportion of the money taken invested partly in new features and partly in workforce benefits.

The greedy consultancy doesn’t follow this path. Instead, it sees the consultancy work – which brings in more money initially – as a process to repeat over and over again. Within a few years, you end up with ten to fifteen individual clients, each with their own support contract and software.

By most measure of success, you are on a winning streak. Income is rising, your portfolio of clients is expanding and you have a wide range of case studies. Your developers are keeping their skills up to date, and when you recruit you make sure that you bring new talents into the business to make future development even more streamlines.

Except … at some point, your bluff will be called and the support will be needed. You’ll then be faced with a number of stark truths:

  • Your developers, individually, have to be skilled enough to support every single one of the systems that you as a consultancy run, as well as being able to push new developments forward; it is very rare to have an entire team with this level of expertise.
  • With developers staying with individual employers for an average of 2 to 3 years each, the chances are constantly increasing that the last person to work on that system has now left the company.
  • Due to its age and your requirement to push the company forward technologically, the software uses technologies – and, sometimes – even languages – that are unfamiliar to the current development team. Therefore the support work will often land on just one or two individuals within the company.
  • Because of the amount of work coming into the company, any familiarisation with existing clients’ code is put to the side as being of little economical value compared with the new business being won.
  • A single support call can easily cost an entire man-day in time when all the above are taken into account. That’s an entire man-day gone from the project they were working on, an increase to the risk of the project delivery date slipping back, and thus a direct effect on cashflow.

This is the tipping point in a software development consultancy. If your company is following the consultancy model, then start thinking of a product. Or, if you’d prefer, work out how many support calls it would take for your company to go bust. I’m willing to bet it won’t be a big number.

Categories: Development Tags: , ,

But … what does it do?

September 23, 2011 Leave a comment

One for the C# developers; another sample of the code previously described here and here. Without running the function below, describe exactly the format of its input parameter, the expected output, and what the hell the developer was thinking at the time.

 //get date in ddmmyyyy format
 public static string ddmmyyyyDate(string strdate)
    {

        const string pattern = "^(?<Day>\\d{1,2})(\\/)(?<Month>\\d{1,2})(\\/)"
                       + "(?<Year>\\d{4})$";

        System.Text.RegularExpressions.MatchCollection mc =
                       default(System.Text.RegularExpressions.MatchCollection);

        mc = System.Text.RegularExpressions.Regex.Matches(strdate, pattern);

        if (mc.Count > 0)
        {
            string strMonth = mc[0].Groups["Month"].Value.PadLeft(2, '0');
            string strDay = mc[0].Groups["Day"].Value.PadLeft(2, '0');
            string strYear = mc[0].Groups["Year"].Value;

            string strDateNew = strMonth + "/" + strDay + "/" + strYear;
            return strDateNew;
        }
        else
        {
            return strdate;
        }
    }

For completeness, the code also has another function ‘mmddyyyyDate’ with exactly the same signature and content.

Categories: Development Tags: , ,

Opening the box: 2 of 2

September 22, 2011 2 comments

In my previous post, I extolled the virtues of a system developed by another software development firm, which had been passed to us for evaluation and potential support and maintenance. As a result, I thought it best to calm the rhetoric down slightly when discussing the code.

First things first, check the connection to the database. Curiously, we’d already noticed that the application was working despite us not having changed the connection string. Must be some magical force we’re not aware of.

Ah, sadly not. They’ve very kindly left their original SQL server wide open for us to use. Firewalls just make development awkward, so it’s good to avoid them.

Then I found this, which brought me right down to earth again. It’s a typical example of the level we’re looking at:

Just to clarify exactly what is being shown here:

  • A function, having checked (across several ‘if’ statements – they obviously don’t know what && and short-circuiting is) that they need to output a message, then:
    • Takes a simple error message.
    • Hard-codes every single bit of styling (fonts, etc) into the HTML, and embeds the text string somewhere into this.
    • Adds that HTML into a text string.
    • Outputs this text string in such a way as it becomes a parameter into a function call to be rendered by the browser through a jQuery plugin.

Then, this …

Now, personally I’d have just used CSS classes, and had the message as a parameter into a template defined in a separate resource file – but, I’m picky like that.

For a start, it may be that they simply haven’t heard of stylesheets:

… or “Stored Procedures” ….

… or “SQL Injection Attacks”…

Several steps beforehand, it does filter out some characters – < > \ ” ‘ % ; ( ) & – but the fact that they’re filtering it in the first place means that they’re already doing it the wrong way.

I could go on, but – on a serious note – this was code delivered to a client expecting a professional level of service. Whether this is typical or not I don’t know, but it’s a simple example of why, if you cut corners in your development budget and go for the cheapest quote, you will end up paying more in the future.

Technical debt is a big problem in the software development industry. We will take this client on, but under the strict instruction that they will pay us for a rewrite, from scratch, of the entire back-end. Whether they will accept it or not, we don’t know; after all, they don’t know what’s inside the magical black box. And until it impacted on their bottom line, they didn’t even care.