Dominic Burford - Professional Profile

This is a great article[^] on how good programmers deal with bad code. We've all written bad code, and we all have to deal with the bad code of other programmers. So finding a few rules of thumb for dealing with all that bad code can only be a good thing right.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I've just finished reading Javascript: The Good Parts[^] by Douglas Crockford[^] and can't rate it highly enough. As a web developer who comes from a background using languages such as C++ and C#, there are several confusing features to the JavaScript language. And even if you're a JavaScript guru, it certainly won't do any harm to read this book to refresh yourself of the good parts of the language.

The book takes the reader through the parts of the JavaScript language that make it the powerful language that it is (of which there are many). It also describes the awful parts of the language that can cause confusion or lead to errors.

Basically if you write programs using JavaScript then you need to own this book. It's not a huge book and you can read it in a few days. The effort of doing so is definitely worth it. You will have a better understanding of the language and know which part to use, and which parts to avoid.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I have used Resharper[^] from JetBrains for several years now, and think it's a great tool. It has many features that greatly improve the productivity of the .NET developer.

I do have one concern regarding it though, and this is that it can lead to developers blindly implementing code suggestions from Resharper without thinking. I call this condition "sleepwalking through code". This is a condition mostly found in junior developers, but can be found in senior developers too.

Within the Visual Studio IDE, Resharper will make many suggestions from it's extensive library of code rules. There are literally hundreds of them. It is far too easy to simply accept these suggestions without any thought. And it is precisely this lack of thought that bothers me.

I inherited a project at a former company where the previous developer was a junior. It was clear beyond any dout that they had blindly followed every suggestion from Resharper. Even down to the indentation.

- They used var for every single variable declaration (I have previously written a blog[^]post on this being a pet peeve).

- They omitted the this keyword when referring to instance methods and properties. The this keyword confers valuable information as it tells us the scope of the variable, and helps to denote instance methods / properties from local ones.

These are both Resharper suggestions, and I have both options switched off. I am able to carefully consider Resharper's suggestions, and have deemed that I don't require these particular suggestions to be made. The junior developer was not able to make such a distinction and blindly followed every suggestion made by Resharper.

On the one hand tools such as Resharper can improve the quality of the code, but it can also prevent the developer from thinking for themselves. Use of such tools needs to be exercised judiciously. I want to see developers who can think for themselves, and even question what they are being told. I don't want people blindly sleepwalking their way through the code. That's a recipe for disaster.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Interesting to see C# lagging behind C and C++. It's also interesting to see R getting such a high ranking too.

Link to article[^]

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

After a year of previews and one release candidate, Microsoft today officially launched the latest version of its Visual Studio integrated development environment (IDE)[^] together with an update to its .NET framework.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Is it really Google's responsibility to solve the world's social problems? Or more accurately, to brush them all under the carpet so that they are hidden away where they can't be found on the Internet. Perish the thought of offending anyone's sensibilities that the world may not be the Utopian haven they thought it was.

The world has problems, but is breaking Google really the best way to fix society?

Google’s mission is to organize the world’s information, not rearrange the world's information to solve society's problems.

Hiding information in the ways described in this article[^] doesn't solve anything, it just makes it harder to fix them by making it harder to find. In fact, it makes it worse, by skewing the information so that it appears there isn't a problem at all. Skewed information is worse than no information.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Sometimes as developers we have to make a stand for quality. Whilst we need to understand the pressures that the business is facing and be sympathetic to its objectives, we also need to ensure that we don't unwittingly hamper those objectives. What I mean by that, is that we can inadvertently do more harm by simply doing what we are told without question, than by making a stand for quality and saying no to something we have been asked to do.

I can remember having a very frank exchange of views with a project manager. I was asked to make a change to an application because it was showing incorrect results on the screen (it was an Android app I was working on at the time). After some investigation, I discovered that the problem lay with the underlying data, and not the application itself. Basically, all the business logic was performed by the back-end system, and the tablet device would just display whatever data it was given. The application contained no business logic whatsoever.

I mentioned to the project manager that the underlying issue was in fact the back-end system sending the wrong information to the device, and that it was this that required fixing. Garbage in, garbage out.

The project manager was adamant that I needed to fix this quickly on the device. I made it clear that the data would be wrong everywhere else this data was used including other applications within the organisation. The project manager refused to budge and the debate could be heard by everyone in the office. Eventually, the IT Director intervened, and thankfully backed me up. A ticket was raised to get the issue fixed by the team responsible for the back-end system.

Had I just rolled over and done what I was told, the defective data that was the cause of the problem would have been fixed in one application, but would have required fixing in all the other applications too. A time consuming and expensive solution to the problem. Fixing it in the one place is clearly quicker and cheaper than fixing it in many different places.

Bear in mind that when I had this discussion, I was still on probation. I won a lot of respect that day, and people knew that I was not a "yes" man and would challenge authority if necessary.

We've all put in those quick fixes when necessary, and that's perfectly fine (within reason). But that quick fix shouldn't negatively impact other applications or areas of the business.

Making a stand for quality is about doing what is right for the business as a whole.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Following on from my earlier blog post Five Truths about software development[^] here is the second installment.

1. As soon as you leave a company to work somewhere else, you will always be blamed for all the awful code when you leave - whether you wrote it or not - for years to come
2. No matter how much testing a developer does, another developer/tester/anyone will find a bug in it in under 5 minutes
3. Trying to explain something technical to someone non-technical is one of life's biggest challenges
4. The intake of breathe you make when you realise just how much that useless IT consultant is getting paid to propose solutions you know he won't be around long enough to witness (but which impressed the company executives by using every buzz word you can throw a stick at)
5. When you try to explain why you need to revisit all those bodges and quick fixes you put in to get the release out on time, suddenly management seems to have gone deaf

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

We've all heard about the full stack developer. That mythical beast who can do it all. Build user-interfaces, write backend business logic and write all the data-definition logic, stored procedures and views. They can do it all. The jack of all trades.

The problem with a full stack developer is that (with few exceptions) they will only be good at some of those aforementioned skills. The reason is that they are diverse and require different skills, a range of skills that very few developers will have. To be able to develop great looking user-interaces, concise and well implemented business logic and peformant data handling code are different skills. It's akin to asking a musician to play guitar, drums and sing. Some musicians can do all of these, but most will specialise in one maybe two. And so it is with software developers.

Most software developers can (and do) have all these skills, but they are rarely great at all of them. It takes time and effort to become skilled at just one of them, never mind all of them. Most companies can't afford UX esperts, backend coders and database admins, so they try to get the best of all worlds by rolling all of these disparate skills into a single developer. Developers are forced to become generalists, rather than specialists

I am far better at design, architecture and writing good quality application code than on creating fantastic looking UIs. Whilst I can create a UI, I won't create one that compares with one that was created by a UX expert. This is the compromise that all full stack develoeprs bring.

This is a hard lesson that many businesses don't seem to want to hear. Until they do, there will always be a demand for the mythical full stack developer.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^] gives some hard evidence to suggest that C# is not as popular as it once was. Which is understandable, it was first introduced back in 2000 and is now 15 yers old. Having said that, there is little chance of C# disappearing off the radar altogether. There are still plenty of C / C++ programmers out there, and even languages like COBOL are still widely used.

I suspect the reasons for this drop in C# may be two-fold. The rise of the mobile market and the rise of the Javascript frameworks for web development.

Despite tools like Xamarin bridging the gap for .NET developers into the mobile market, there is no substitute for native development, especially where you need to use the device's native features such as GPS, camera, contacts etc.

With the meteoric rise of Javascript based frameworks on both the client and server, there is a huge gap in the market for developers with good Javascript skills. So that might account for some of the waning numbers. I am one of those .NET developers who is learning both React.js and Node.js, but still keeping my core skill set up to date.

I'm certainly not worried, and nor should any other .NET developer be worried. However, it's always a good idea to make sure your skills are current and you have other strings in your bow to fall back on. Learning a mobile technology and / or a Javascript framework won't do you any harm.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This is the first part in what will hopefully be a series of blogs. Stay tuned for further truths about software development in up and coming blogs.

1. No matter how well you have designed a piece of software, another software developer will always tell you how their way would have been better
2. A requirements specification always misses out at least one absolutely vital piece of information
3. Software developers love to moan and complain about the work of other software developers
4. That beautifully crafted piece of shiny code will eventually turn into a steaming pile of spaghetti code - it's only a matter of time
5. A happy software developer is one that is using the latest, shiniest new technology (or "toys" as they are usually called)

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Software development is not a 9 to 5 job. It's a passion, a way of life. It requires enthusiasm and motivation to spend time constantly learning new technologies and trying to stay fresh and at the cutting edge. When you lose that edge you go stale and that's never a good thing in such a fast moving industry. People who thrive on change thrive within the IT industry. It's certainly not for people who like the status quo.

There's a well known phrase that says "If you're not moving forwards, then you're going backwards". In IT this adage is very true, and is probably the reason why people who work within IT spend time reading around new technologies. So they stay fresh and current.

I regularly spend time reading around new technologies (Twitter is great for this), contributing to technical forums and writing technical articles and blogs.

Eat, sleep, geek, repeat.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

If you have ever had a discussion with a software developer regarding an issue relating to technology, then you'll no doubt have experienced how fervently some can hold onto their opinions regarding their favourite tools and / or technologies. This is especially true when it comes to their programming language of choice. I have lost count of the number of times I have been dragged into a flame war over some programming language, methodology or some other technological aspect of the software development life-cycle.

- C# vs Java
- PHP vs ASP.NET
- C# vs VB.NET
- SQL Server vs Oracle
- Apple vs Microsoft
- iOS vs Android

The list goes on.

Software developers expend a great deal of time and effort learning a particular technology, and have an emotional attachment to it because of this. For most software developers, myself included, developing software is more than just a job. It's a passion, a vocation. We live and breathe what we do. We spend time outside of our day jobs reading around and learning new tools and technologies, contributing to open source projects, writing about technology (as I'm doing here), answering technical questions on forums, all in our spare time.

There is a wide gulf between familiarity with a technology and mastering it. We tend to choose and favour tools and technologies that align with our deep seated, deeply entrenched views and philosophies on the nature of software development. Software development is an extension of ourselves. It is this emotional response that makes us less than objective sometimes when discussing technology. It is hard to be completely subjective about something for which we have spent a large amount of our lives learning and mastering.

If you develop software using a particular language, and spend time with that same community on online forums and the like, then it's no wonder that when faced with a particular problem, you always see the solution as being to use your language of choice. You have software tunnel vision. When you are hammer, all you see are nails. This behavioural pattern helps reinforce our technological decisions and seals our beliefs even further.

Software developers naturally want to protect their investment in their chosen technologies. They want to ensure that their investment in time and energy rewards them well into the future, so that they don't become expendable. Software developers will defend their technological decisions, even sometimes when clearly making a poor argument such as when the technology is poorly aligned with the problem space.

I certainly can't see flame wars ending any time soon, so maybe it's time to don the kevlar suit and try not to get burnt.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I'm sure we've all done it, and we've probably all heard other developers do it too. Complaining and criticising about someone else's code.

- "It's the worst code I've ever seen"
- "This guy's code totally sucks"
- "The guy who wrote this mess should hang his head in shame"

Sound familiar? On practically every forum where developers can hang out you'll hear them complaining and criticising other people's work. It seems to be endemic to the industry so prevalent and ubiquitous is this behaviour.

Imagine if other professions did this. Electricians, plumbers, mechanics. Imagine if you took your car in for a service, and every time you did, the mechanic complained and criticised the work of the previous mechanic.

And yet this is exactly what every software developer does.

Let's turn back the tide, and change this negative behaviour and accept my challenge. For one week, do NOT complain or criticise anyone's work. Try to find something good to say about all the work that you come across. No matter how bad the work may be, find something positive to say about it.

- "The code may not have scaled very well but it was easy for figure out what it was doing"
- "At least the code at fault was consistent with the rest of the code-base"
- "The error logging was pretty good"

Get the idea? For one full week remember. Let me know how you get one Smile | :)

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

You'll be singing a different tune the next time you have to change that SLA code.

I totally agree though. Once I found myself complaining about some old code then realised I wrote it. It's a huge waste of time and energy.

It seems to be endemic to our industry. Developers love to moan about another developer's code. And yes, it's a total waste of time.

Now back to that SLA code Big Grin | :-D

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

One of the founders of CODE Magazine gives a great summary of the last 15 years of CODE Magazine[^].

I have read both MSDN and CODE magazines but have always preferred the latter. I find the articles tend to be more useful.

Congratulations to everyone at CODE Magazine and keep up the good work Smile | :)

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

There seems to be a growing trend amongst certain quarters to criticise businesses for the manner in which they have adopted Agile. These criticisms seem to be from Agile purists who have taken umbrage as the businesses in question have not precisely followed the ideals as laid out in the Agile Manifesto[^]. I've read several articles that have been critical of the way that a particular business has adopted Agile.

"That's not how you do Agile"
"That's not following the Agile Manifesto"
"You can't say you are an Agile shop unless you follow Agile to the letter"

I am not and have never been a purist of any particular methodology, including Agile. Every business is different, with different processes, skills and people. Whilst there are clearly certain ways to do Agile wrong (such as following a process that more resembles the waterfall), there are many ways to do it right.

For the record, I have worked in an Agile software team and found it extremely beneficial and highly productive, so this is in no way an attack on Agile. When used appropriately, Agile can bring huge benefits to a team.

Do these same Agile purists rigidly follow the SOLID principles when writing their code? Do they slavishly follow TDD and have 100% test coverage across their code? The answer is (almost certainly) no, of course they don't. Purism only has a place in academic text books. In the real world, pragmatism comes into play. The gulf between theory and practice can often be very wide.

Agile is not a prescriptive, deterministic process. It is a set of ideals that can be tailored in ways that are appropriate to the business. So what if your daily scrum is around a table with everyone seated, instead of around a Kanban and standing up. These are details. It doesn't matter. The key points are that you are building software in a way that is responsive to change and with key stakeholders involved from the business. It's important that you have fostered closer relationships with your customers who have greater input into the project. It's important that your team is evolving into a self organising team capable of taking responsibility for what it does.

There is no room for such pedantry in the modern business. It's hard enough just getting product out the door, without also having to ensure you haven't fallen foul of any of the ideals laid out by your methodology of choice.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I'm sure all software developers will be well aware of the dangers of spaghetti code. That nightmarish code that is rigid and inflexible by nature, and difficult to comprehend and maintain. Changes to spaghetti code are hard to implement and are fraught with unexpected side effects which often result in making the code worse instead of better.

But how does spaghetti code get created?

Spaghetti code just doesn't arise spontaneously though. Very rarely does a single software developer sit down and write a whole bunch of spaghetti code. More often than not, spaghetti code started out as the new kid on the block, all shiny and new. Well designed, well implemented and totally rocked. However, just before shipping, a bug was found, and it needed fixing pretty damn quickly (PDQ). So a hastily implemented fix was put in place, and everything was sorted.

Due to project delays and time pressures on the next release, no one had the time to go back and refactor the code, so the hasty fix remained. After releasing the software, a very vocal customer shouted very loudly that they needed a feature for them to use the software. They shouted again, and the software manager agreed to give them what they wanted. So another hastily implemented feature was put in place. A few more vocal customers also shouted very loudly and they too also got their features.

Just before shipping, a few urgent fixes were found in the unscheduled features that were implemented to appease the shouty customers. These had to be fixed PDQ.

And so on and so on. Vocal customers demanding unscheduled features. Bugs found late in the process before shipping And never the time to revisit the code to make it all shiny and new again. It doesn't take long before that shiny new code that totally rocked, has gradually degenerated into a sloppy heap of spaghetti code.

There is no simple solution to this problem, and an entire book could be devoted to the subject, but it's usually a combination of one or more of the following that leads to spaghetti code.

Inexperienced software developers
Poor project management
The business failing to acknowledge the problem and address the ever growing problem of technical debt (an issue I have discussed previously here What is Technical Debt?[^]

The first two problems can be rectified without too much difficulty by training and education. The latter is more problematic however. Getting the business (any business) to spend time going back over the code and refactoring it when they have already agreed new functionality and deadlines with the customer is nigh on impossible. It is easier knitting spaghetti than to persuade the IT Director of the importance of technical debt. Yet the concept is stunningly simple.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Having used Xamarin to build enterprise apps for the Android platform, and having spent some time investigating Apache Cordova, it’s clear that there are some key differences in the approaches that each tool has taken.

Both technologies allow developers to build cross-platform mobile apps, but they achieve this in completely different ways.

Xamarin allows a C# developer to build apps using Visual Studio (or Google Studio / Eclipse if that is their preferred IDE). Xamarin is firmly aimed at the enterprise developer where porting business logic to the different platforms is critical. The UI for each platform will (in most cases) be re-developed for each of the different platforms. The Xamarin developer builds cross platform assemblies that can be ported to the different mobile platforms. The UI is then built on top of these assemblies.

Apache Cordova takes a different approach. It runs the app in a Webview control using the device’s browser. The Webview takes care of the device settings and configuration for the specific platform. Apache Cordova is firmly aimed at the web developer wanting to build cross-platform apps using their existing knowledge of HTML5, CSS3 and Javascript. Using web technology enables the app to be run within the device’s browser. The business logic and UI are therefore completely encapsulated within the web app.

Although there are other players in the cross platform arena, both Xamarin and Cordova are gaining traction and popularity. If you’re looking to get into cross-platform development and not sure which way to go, you could always start by looking at the core competencies of the development team and the business itself. If you’re already an enterprise C# developer, then Xamarin may be your natural starting point. If you’re already a web developer, then Cordova may be your natural starting point.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^ gives a good summary of the stages a professional software developer takes throughout their career. From junior developer right the way trough to senior developer.

What qualities should a senior developer have though? Here are my own qualities that I would expect to see in a senior developer.

At least five years working in the industry. Some people say three years is sufficient, some say at least ten. I think it depends on how much variety they have had within that time that is important. Experience from working from a variety of projects using different tools and technologies is the key.
This segues nicely into my second point. A senior developer should have a broad range of skills covering areas such as design, requirements and coding. They should be able to apply good business sense to a project. Rather than just using the latest shiny technology, they should be able to pragmatically apply the most appropriate tools and technologies to the project to ensure it meets the customer's expectations.
They should possess good design skills. They should have familiarity with design patterns and the SOLID principles.
An appreciation of the different lifecycles, and their key strengths and weaknesses. For example, when and why would you use Agile? What is Test-Driven Design and why would you use it?

In summary, a senior developer should have a wide range of knowledge, covering all aspects of the software lifecycle, coupled with a deep understanding of their current tooling. They should be sufficiently experienced that they could mentor a graduate / junior developer.

There are no hard and fast rules, so this list (or indeed any list) of qualities and attributes expected in a senior developer will always be completely subjective, but hopefully this list gives a good starting point.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^] gives a very pragmatic means of implementing the CQRS pattern in a typical ASP.NET MVC application.

I came across CQRS[^] late last year when a colleague pointed me in the direction of DDD, event-sourcing and CQRS. It's great to see an article that makes it simple to implement in practically any project. I suspect part of its lack of widespread adoption is that it's simply viewed as an enterprise pattern that isn't applicable for use in the everyday application.

Maybe now we will begin to see CQRS being implemented more widely.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Over the years I have worked for four software companies (and am currently employed at one as I write this), as well as non software companies including the public sector, a publishng house and for the UK's largest IT outsourcer.

Although there are probably many differences between the individual companies, one thing that has struck me is the level to which software is granted the status of a core competency at a software company.

At a software company, software is king. It is the core domain of the business, and therefore there is far more innovation and R&D relating to software within these companies. They tend to have better processes, early adoption of new and emerging technologies, and dare I say it, better developers. I appreciate that there are great software developers everywhere, but the best ones seem to be drawn to software companies. If your passion is for developing software, then it makes perfect sense that you want to work for a company that specialises in that domain.

This is the key difference between working for a software company, and a non software cmpany. At a software company, the software is king. Everywhere else, software development is a support function. It enables internal business processes and automates manual tasks that are likely to be error prone. But there is a huge diffefence between developing software that supports the business, and developing software that IS the business.

Even if you work for a well known high street brand, software is still a support function to the key competency of the business.

I have always preferred working for software companies and wouldn't want to work anywhere else.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

A friend of mine was due to visit me over the weekend, but was somewhat delayed due to a problem with work. Despite this being a Saturday and he was not working authorized overtime, he was running late due to having to sort out a problem with the web site where he works (who shall remain nameless). The web site had been hacked and needless to say the issue needed resolving quickly. The problem was, no one was actually tasked with having responsibility for the web site. My friend who was sorting out the problem has no official jurisdiction over the web site whatsoever. He was only asked to investigate the issue as it was widely known that he had an interest in web sites outside of work. But officially, he has no responsibility for the web site.

My friend’s manager was unable to help due to his lack of technical expertise. He is a general purpose manager who delegates the workload to his team, but he doesn’t actually have any technical expertise himself.

The IT Director was unable to help for the same reason. Although he does have some technical expertise, he wasn’t sufficiently skilled enough with the specific technologies to be of any help in resolving the matter.

So the responsibility of resolving the issue fell on my friend. On a Saturday when he had other plans.

IT weren’t even fully aware of the web site, as it was brought into the business without them being consulted. Apparently the Marketing department wanted a web site, and went out and secured one. IT weren’t consulted, and so refused to accept any responsibility for its maintenance. They therefore assumed that the web site had not been commissioned.

What a sorry mess all round.

I’m sure I don’t need to spell out the huge errors that this situation highlights.

• No one had responsibility for the web site and therefore there was no single point of contact to go to when it became hacked.
• There was no one skilled enough within the business to resolve the issue when it occurred.
• There was no escalation procedure in place.
• Consulting the various departments and getting their buy-in before introducing a new application into the business is paramount. If you need IT to support the system, then they need to be fully consulted before hand.

If you’re going to have a web site, or indeed, any corporate / enterprise software application, you need to ensure that there is sufficient skills to maintain it when it inevitably causes problems. It is nothing short of incompetence to do otherwise.

Needless to say, my friend will be raising this issue first thing Monday morning, with solid assurances that the matter will be fully discussed with action points so that it doesn’t happen again.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^] is the perfect follow up to a previous blog I wrote entitled Bankrupt Development[^] where I call into question the ethics of our profession.

Quote:
We, software engineers, have superpowers most people don’t remotely understand. The trust society places in us is growing so rapidly that the only thing that looks even remotely similar is the trust placed in doctors. Except, most people have a pretty good idea of the trust they’re placing in their doctor, while they have almost no idea that every time they install an app, enter some personal data, or share a private thought in a private electronic conversation, they’re trusting a set of software engineers who have very little in the form of ethical guidelines.

As with any profession, conducting yourself in an ethical manner is of paramount importance. Software is becoming more and more ubiquitous. We are increasingly becoming more dependant upon software for every part of our lives. From cash-points, to our cars, washing machines, smart phones, apps, the internet to name just a few. Software permeates every part of our existence. Yet very few understand what we do. But like good scientists, it is our duty to break down the barrier between our profession and the public and to be as transparent as possible, to take care to explain what we do as clearly as possible, and to ensure that we act in the interests of the public at all times. We are accountable for our actions and need to ensure that we take responsibility for those actions.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Dominic Burford - Professional Profile

Summary

Reputation

Privileges