Archive

Posts Tagged ‘Technical Debt’

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.

Advertisements

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 …