November 17, 2011 Leave a comment

One of the nice things about being in a senior position within a small company is that, every so often, you come across a situation that happens so rarely that no documentation nor process exists, and it’s entirely your responsibility to work out from scratch what needs to be done.

Being the most experienced within the company on our infrastructure and security, it fell to me to write the procedure for ensuring that any individual leaving the company is locked out as securely as possible. As I write this, less than a day away from leaving my job at Acme, the person leaving the company – the person who needs to be locked out – is myself.

The standard technical parts are easy enough: change all admin passwords, change every single password in the Password Database (Yes, it will take a while. Yes, I did advise against it. No, I can’t help. Because then you’d have to tell me the new passwords!). But two major unknowns exist; one legal, one social.

Legal Lockdown

The legal part is relatively simple: make it clear to the soon-to-be-ex employee (STBEE) that they are no longer entitled to access the company’s systems by spelling out, in as much detail as required, that their access is revoked to:

  • Any company system
  • Any system run by the company on behalf of a client
  • Any system run by a client whose access has previously been a privileged right of the company

except for those rights granted to any other anonymous or generic individual; this allows, for example, a STBEE to visit a former client’s website, but not to use any security credentials on that site that may have been supplied as a part of their employment.

It may be advantageous to get the STBEE to sign a document agreeing to the above, just to ensure their understanding is complete.

Social Networking

The social part is where the rabbit hole opens, and specifically social engineering. A company can spend all its time locking an individual out, but there is always the risk (depending upon the nature of the departure) of the user contacting third parties claiming to be acting on behalf of the company.

  • How do you protect against a email being sent to your hosting provider, designed to match the style of your infrastructure manager but cancelling a client’s service?
  • How can you stop a rogue employee contacting the IT department of your biggest client and creating a new account that acts as their backdoor?

The only chance that a company has to counter this is to make sure that the other usage of social is taken into account: communication.

  • Ensure that all employees, clients and suppliers are aware that the individual is no longer an employee.
  • Ask that any supplier always confirm any out-of-the-ordinary request, either by email or phone.
  • Ensure that any change to any configuration or payment is fully understood.

It’s not perfect; time after time, social engineering has been shown to be one of the most dangerous types of hacking in existence and at the same time the most difficult to protect against. But through communication there is still at least a chance.


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.


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 =

        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;
            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.

Opening the box: 1 of 2

September 22, 2011 2 comments

To the majority of people, software development is a black-box process. They contact a software development company, provide them with a specification, some money changes hands and some time later a shiney finished bit of software lands on their desktop ready to use.

Every so often, though, the box needs to be opened. They may lose contact with (or faith in) the original development company. If they’re intelligent enough to have negotiated ownership of the intellectual property, they pass the software onto a third party for them to evaluate, then support and extend according to the client’s wishes.

This happened to a client of ours recently, and I was given the task of opening the box. All I knew was that the original developer had provided us with ASP.NET and C# source code, and a SQL Server database. What I found amazed me, and so to avoid overloading this blog with too much magnificance in one step I am splitting my analysis over two separate posts: this first, for the SQL database, and then a second covering the ASP.Net and C#.

For obvious reasons, the name of the client has been substituted or removed in the examples; other than that, these are all genuine screenshots.

The 40MB database backup was a bit daunting at first, but thankfully the file actually contained five separate copies of the database rather than just the one that most people use (nothing like redundancy!) so it wasn’t as bad as it could have been. The first thing I noticed was that they were being very careful on security – anyone who decided to try a case-sensitive attack on the structure would have been easily thwarted right from the start:

I spotted later, after altering the image above, that their login (which prefixes the table names above) also included a numeric in place of a letter. So ‘clientsN4m3’ would be a more accurate representation of their login. Not their password. Their login. It’s even more secure than I realised.

Their coding style was also very efficient – no need to worry about any standards to read through and memorise when you could make up primary key fields at any point and follow any particular naming scheme that came to mind at the time. I especially loved, in the ‘state’ table, the way that they were free to even use different datatypes if they wanted to:

We obviously have a lot to learn from them here, and even more so when you take into account the relationships in the database itself:

Now, personally I’m happy with a straight one-foreign-key-per-relationship, but obviously they wanted to make sure that, when they added a relationship, they meant it. They were obviously very committed to their database designs, and good on them.

Part 2 continues the theme …

Think of a name … any name. Except that one.

September 15, 2011 1 comment

Many years ago, a client of my employers – call them ‘Acme’ – decided that, rather than calling the system we’d developed for them ‘The Acme System’, they needed a name for it that could be used in conjunction with an upcoming marketing campaign.

After several weeks of thought, they eventually came up with a simple name that they felt epitomised the global intent of their business whilst being a recognisable and memorable English word. They promptly invented a highly contrived (and, long-since forgotten) backronym to justify this name, and went forth. That word was ‘ATLAS’.

In Greek mythology, Atlas was the god who supported the heavens (not the Earth, as many believe) on his shoulders. Not a figure that you would have thought relevant to a 21st Century software product, but the client was happy.

A few weeks ago, I discovered that a friend was having some software written to support a new side to his existing business. The name they had chosen? Atlas. Last week, another client forwarded on a specification for the final stage of an integration project I’m involved with. The name of the system we have to integrate with? Atlas.

Even Microsoft are in on the act; their Atlas Solutions division is responsible for the purchase and placement of adverts on Microsoft’s Atlas advertising platform!

So am I alone in coming across this same name so often? Or have I inadvertently stumbled upon a formerly hidden rule, stating that at least one product in every company’s portfolio must be named after a deity condemned for eternity to stop the sky falling in on us all?

Categories: Development, Microsoft Tags: ,