Dominic Burford - Professional Profile

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

Software development is full of best practices. Indeed entire books have been written on the subject of best practices covering every aspect of software development, from design to coding to methodology to name a few.

I thought I'd throw my own weight into the arena and list a few. These are in no particular order.

Agile methodologies are huge these days. There is an entire industry now dedicated to helping companies adopt agile practices.
Automated testing is something almost universally agreed upon as a laudable goal.
Test driven development may fall more on the controversial side, but there is no shortage of developers out there that think of this as a best practice (certainly when used strategically rather than in a purist manner).
Continuous integration, as opposed to developing in silo branches and then having extensive merging efforts, is also largely viewed as a benefit.
There was the original, so-called, Gang of Four list of object oriented design patterns, but the list of patterns has grown beyond the ones suggested by this group of authors to include many more. All taken together, using these patterns strategically is considered to be a best practice.
Code reviews are widely considered to be indispensable ways of promoting code quality.
Pair programming takes code reviews to the next level and has development performed in a constant state of review.
One click, automated builds are considered an important goal for most organizations, in stark contrast to the practice of having someone labor for half a day to get the software into a deployable state.

I could list many more, and may do just that in a future post. But I think those make a good start.

"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 discussion with a colleague we were talking about the analogies between the civil engineer and the software engineer. In order for the software industry to be given equality with the civil engineering industry, then it should adopt the same underlying principles.

Rigorous requirements
Rigorous design
Repeatable processes
Entry qualifications and external assessment

These are very worthy criteria to aim for, and I would definitely advocate their use. However, there are certain key differences with software engineering.

Software engineers are expected to be able to fit new features onto existing solutions. Imagine if a civil engineer was asked to amend their bridge so that it could accommodate trains as well as cars after it was completed? The civil engineer would quite rightly say that this was impossible or at least so financially costly as to be unworkable. The software engineer however is expected to do exactly this with the solutions they build.

I would definitely like to see more engineering disciplines filter through into software engineering. Particularly entry level qualifications and external assessment. To become a civil engineer and build a bridge you require certain minimum qualifications that have been verified by the industry. In software almost anyone can enter the industry with little or no qualifications and go on to build critical software applications.

There are certainly things we can learn from civil engineering, but there are also key differences between the two industries that we shouldn't forget.

"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 for some very interesting reading.

Quote:
Web developers should learn .Net, Java and C# to improve their employability but will not make as much as other IT roles in the UK despite high demand, according to new research.

To me this seemed a rather strange statement as these are the key skills that many web developers would have anyway. I suspect they may be confusing web designer with web developer.

Quote:
Similarly, customers of all industries are demanding more intuitive applications to interact with businesses. Thanks to this trend HTML 5, Java Script and CSS were the top three front-end skills in demand so far this year.

It's fair to say that web developers are expected to be full stack developers who are comfortable working on the back-end business processing code as well as creating interactive and intuitive UIs.

At the end of the day you should love what you do and do what you love. Money can't buy you happiness.

"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 recently came across this article[^] that demonstrates a high precision Pi calculator written as a Windows batch file.

As someone who got started in programming by writing Windows batch files longer ago than I care to remember, this is certainly impressive.

"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

Whilst working a lot recently with various Javascript frameworks ((React.JS and Node.JS) I came across this fantastic unit testing framework called Jasmine.[^]

Quote:
Jasmine is a behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM. And it has a clean, obvious syntax so that you can easily write tests

If you're developing any sort of application that uses Javascript then you need to check this framework out. It's very easy to use and can be used in a TDD style approach.

"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 following article[^] outlines the ways in which enterprises are failing to fully grasp the importance of open source software.

In a nut shell.

Quote:
Enterprises continue to fumble open source, largely because they misunderstand its value

Just as there is more than one way to swing the proverbial cat, so there is more than one way to increasing the bottom line. Selling software is certainly one way, but it isn't the only way.

Open source is a great way to advertise your skills, products and services. It can lead to higher quality software by allowing other developers to sweep through the code and find and fix defects. Apart from the development side there is testing, documentation etc that can also be harnessed by the open source community. The key word is community. To fully embrace open source and to maximise the benefit you get from it, you need to build a community around what you do. You need look no further than the mighty Microsoft and its recent strategy of opening up its development code bases (C# compiler, MSBuild, ASP.NET) for proof that the strategy can be an extremely successful one.

Giving something away may just be the best way to increase your bottom line.

"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 craftsmanship is more than simply having pride in one's work. It's a two-way street. A craftsman approach also helps increase the respect of the business for their IT professionals, who bring high-level expertise and a sense of purpose that will advance the business. In software, developing a deep obsession with the customer's needs is part of being a craftsman approach. After all, obsession with customer satisfaction is what helps business succeed at the highest level.

A few years ago, these values were enunciated in the Manifesto for Software Craftsmanship[^] (with more than 16,200 signatories so far), citing the following values:

Quote:
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships

The manifesto has a very similar vibe to the Agile Manifesto[^], and that's no accident. Agile principles are an important part of software craftsmanship, which also advocates a higher-order role for developers:

Quote:
Although software craftsmanship is not a methodology, it strongly recommends the adoption of certain technical practices and disciplines, mostly the ones defined by Extreme Programming. With a great synergy with Agile and Lean principles, software craftsmanship promises to take our industry to the next level. Professionalism, technical excellence, and customer satisfaction are the main focus of software craftsmanship. One of its main focuses is changing the perceptions that software developers are like workers on a production line and that software projects can be run as if running a factory.

"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 long been an ardent advocate of open-source software, and happily contribute to it when I can. I posted my Subversion to Bugtracker.NET application on my Github[^] page for example.

This article[^] nicely summarises why open-source software is becoming more than just a hobbyist past-time but increasingly becoming part of the enterprise software landscape.

"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