Dominic Burford - Professional Profile

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

Any article[^] that claims to describe the skills needed by a developer is naturally going to be out of date fairly quickly. Nonetheless this article does a pretty good job. My only criticism is that Node.js is missing. This is inexcusable. If I had to list just one skill that EVERY web developer needed to learn it would have to be Node.js. I’m not sure how the Go programming language can get a mention but not Node.js.

I’d also like to have seen a mention of Progressive Enhancement (PE). For those that haven’t heard of it, PE is a design strategy aimed at making web applications more inclusive by ensuring that the applications can work from the least enabled (in terms of browser versions and features) and upwards. With the current ubiquity of Javascript frameworks, PE is more relevant than ever before.

"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 been using Visual Studio Code[^] for nearly a fortnight now and have to say that it's pretty damn good. I've been using it for web development as well as Node.js develolpment. In both cases, it works extremely well.

Up until installing Visual Studio Code, I've been using the Sublime code editor (which incidentally is very good) for my Node.js development. But I wanted a tool that had good support for Javascript, and Node.js in particular. And to that extent I am very impressed. Visual Studio Code has great Node.js support and even allows for debugging your applications.

I've also been using Visual Studio Code for my web development. It may not have all the features of it's big brother - Visual Studio - but it contains more than enough features to keep this software developer happy.

All in all, I'm very impressed with Visual Studio Code. It's very compact and has a nice, clean UI that is very simple yet powerful. If you are serious about software development but want something a little less cluttered, then check it out.

"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 developers solve problems by creating software solutions. That’s our job and that’s what we’re paid for. However, just because we’re asked to create a piece of software doesn’t mean we should immediately go ahead and implement it. There may be other ways of solving the problem that don’t necessitate creating a software solution. The problem may be solved by a change to the underlying business process or by utilizing another software application for example.

I was recently asked to investigate a problem that a customer had reported with one of our products. Their request was very reasonable and I started looking at ways of solving it. The proposed solution was to provide a patch to the product which would solve their problem. All this was perfectly reasonable.

Upon further investigation and asking a few more directed questions to the support team, I ascertained that the problem was specific to only this particular customer, as no one else used the product in the same way. Further to this, to create a patch would take time. A software developer would need to fix the code. A tester would need to test it to ensure it worked without adversely affecting the rest of the product. We would then need to create the patch and distribute it to them. During all this time other work would not be getting looked at. It could therefore take several days to get the patch to the customer during which time other work would have to be put on hold.

My proposal was to simply fix the affected data directly by executing a few SQL queries on their database. It was quickly agreed that this was the more effective solution and the support team were very quickly on the case. By the end of play that same day the data was fixed and the customer was happy, and so were we as it saved us a lot of effort. All in all a very successful outcome.

So before you write a single line of code, it’s always worth considering alternative solutions, particularly if the alternative has a quicker and cheaper yet equally effective outcome.

"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

Really interesting article[^] where Stephen Hawking speculates that human intelligence will be overtaken by artificial intelligence over the next century. This is not the first time that such conjectures have been made, by either Stephen Hawking or other scientists / thought leader including Elon Musk and Bill Gates.

Quote:
Computers will overtake humans with AI at some within the next 100 years. When that happens, we need to make sure the computers have goals aligned with ours

Whilst easy to dismiss as science fiction hyperbole, the danger is that intelligence is based upon connections which increase at an exponential rate. The human brain is wired to connect synapses, and electrical current passes between these to create thought. A single synapse is connected to many other synapses, which in turn are connected to other synapses, which in turn…..you get the idea. You don’t need many synapses to very quickly grow a vast amount of connections (an exponential number). Artificial Intelligence is based upon exactly the same architecture, only instead of cellular connections there are digital ones. The point is that intelligence can grow very quickly given limited input, and exponentially increase thereafter.

The irony is that our own intelligence may turn out to be our biggest downfall.

"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

In a recent blog entry[^] by Andy Hunt, one of the original authors of the Agile Manifesto, he openly criticizes the current state of Agile adoption. He makes the argument that far too often, Agile is adopted in a prescriptive and inflexible way. The whole point of Agile, as indicated by its eponymous name, it that it should be “agile”. Many proponents instead have taken the Agile Manifesto as a prescriptive set of doctrines to be slavishly followed. Agile however was never intended to be a process, but instead a set of best practices that could be implemented to align with the needs of the business.

Just like a design pattern is a general solution that is intended to be implemented in a way that fits the needs of the application, so Agile is a set of best practices that are intended to be implemented to meet the needs of the business.

The blog posting offers a way to power out of the rut, however, and it centers on a method that Hunt refers to as GROWS, or Growing Real-World Oriented Working Systems. In other words, software grows and changes based on real-world feedback and actual evidence, until it reaches a state in which it actually works. Hunt advocates the use of the Dreyfus Skill Model within this framework, as a way of on-ramping less-experienced developers while allowing their veteran counterparts more flexibility.

Quote:
“Whatever we attempt here has to work for the whole system, not just the developers, not just the managers, not just the testers, not just the users, not just the sponsors,” Hunt concluded. “There is no ‘us’ versus ‘them.’ There is only us.”

"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

Further to my previous blog post[^] on learning Node.JS, I want to recommend another book on Node.JS. In my previous blog post I had purchased a book called The Node Beginner[^] which is an excellent introduction to anyone wishing to learn Node.JS.

I have since bough the follow up book called The Node Craftsmean Book[^] by the same author Manuel Kiessling[^]. This book is every bit as good as his first book. It picks up where the first book left off by going through some more advanced aspects of Node.JS such as callbacks, asynchronous execution, event emitters and working with MySql and MongoDB. You then use these techniques to build a fully working Node.JS application.

The writing style is simple and easy to understand and by the end you have a fully working application.

I highly recommend both of these books to anyone who either wants to learn Node.JS from scratch or for those with some knowledge who want to dive a little deeper.

"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

Well, my new laptop has arrived and I've been setting up my development environment. With so many free tools around these days it's easier to geek out than ever before.

So far I've installed Visual Studio Code, Visual Studio Community Edition, Reach.js and Node.js. I intend to install SQL Server Express and / or MySQL.

"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[^] makes a good point. Great programmers write code that can be easily debugged. One of the first things I always add to my own applications is error and diagnostic logging. I do this as part of the underlying architecture, not as something I add later on (when it is obviously much more difficult to do so).

Whilst no software developer wants or expects their application to throw an exception, when inevitably it does, they will need the tools to track down and fix the problem. Without adequate logging this is almost impossible to achieve. It is a long and painful process of trial and error. It is a false economy to deliver an application more quickly without logging, as you’ll simply absorb all that time during the lifetime of the application thereafter.

Logging is not just a nice-to-have luxury, it is an underpinning part of the architecture.

"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

In the article In Praise Of The Average Developer[^] Jacob Kaplan-Moss asserts why the myth of the 10X programmer is so destructive.

As developers we all admire those who are on the bleeding edge, those who work tirelessly to stay on the crest of the technological wave and are constantly trying to break into new territory. Those developers who are writing articles about a new technology before we've had a chance to even download it. As developers we are excited by new technologies.

The harsh truth is that the vast majority of us are not like this though. As with any distribution, the majority of us will sit on the top of the bell curve somewhere. And there is absolutely nothing wrong with that.

The rock star developers may be awesome at coming up with fantastic new solutions and implementing new architectures using the latest bleeding edge tools. They may not be so good at fixing bugs and the other mundane tasks that are fundamental to the work of a software developer.

If the industry was filled with these creative geniuses then who would fix the bugs? The harsh reality is that the industry contains far more average developers than rock star developers. Not everyone is able or even motivated to work extra hours researching new technologies. But that's absolutely fine. Whilst the average developer may not set the world alight, they play a vital role nonetheless.

Whilst the industry needs rock star developers to keep pushing the boundaries and seeking out new solutions, it also needs the reliable, hard working average developers too.

"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

The annual Future of Open Source survey confirms what we all suspected: Open source has won[^]

With the mighty Microsoft now fully embracing open-source with many of its developer tools, open-source is now hard to ignore, even for the enterprise.

Quote:
The survey reports that 78 percent of its respondents are now running their businesses with open source software, and two-thirds are building software for their customers that’s based on open source software. More significant, the percentage of respondents actually participating in open source projects has increased from 50 percent to 64 percent, and 88 percent say they expect to contribute to projects within the next three years.

Open source is now no longer viewed as hobbyist projects developed in the spare time the closet geek, but is now viewed with (almost) complete parity with its shrink wrapped cousin. There is still some way to go, but this is certainly very encouraging progress.

"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