Dominic Burford - Professional Profile

Quote:
Contrary to what it may sound like, NativeScript is not a programming language – in fact, it simply uses languages you may already know: JavaScript, CSS and XML. NativeScript is a framework for building cross-platform truly native mobile apps with JavaScript!

This Javascript framework[^] looks interesting. Not only has it got good integration with the Visual Studio ecosystem, but it is capable of creating cross platform mobile applications. Built around Javascript, XML and CSS, the tooling should be familiar to any web developer.

Quote:

The NativeScript promise is simple – you can build truly native cross-platform apps with a single codebase of JavaScript, XML and CSS. NativeScript offers plenty of tooling for the Visual Studio developer – everything from building the app, to testing and deployment. Don’t like JavaScript? Fine, you get to write your app business logic with TypeScript. Choice for developers is a good thing, and .NET developers get plenty of love in NativeScript

.

"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

Just finished reading this excellent book[^] on functional programming with Javascript. I've read various articles before on the same topic, but it's nice to have a book to give you the full detailed picture of the subject. This was a great book, full of useful explanations and examples. Unlike some books that try to make the case for using Javascript in a purely functional manner, this book is more practical, and makes the case for using Javascript in a functional manner alongside your non functional Javascript, therefore making the book appeal to every Javascipt developer, not just academics.

Javascript makes an excellent functional programming language. It supports functions as first class objects whereby they are treated as any other object by the language. They can be assigned to variables, passed to other functions and returned from functions. Javascript also supports higher order functions. These are functions that take a function as an argument and return a function. Higher order functions should not have any side effects or rely on the environment in any way.

Learning functional programming with Javascript is definitely worth the effort. By adopting a functional approach you can make your code cleaner, more modular, increase its reusability, reduce its coupling and can be sure that it is mathematically correct. Programming in a functional manner can also lead to useful abstractions. By passing functions as parameters to other functions you can harness the power of callbacks, which underpin reactive and asynchronous programming.

Even if you only use Javascript for client side validation on your web controls, learning functional programming will not do you any harm whatsoever. Quite the opposite in fact.

"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 involved in Software Configuration Management (SCM). Since 2000 I have been involved in SCM at various companies I have worked for. I find this an interesting and challenging part of the software development process. It doesn't matter how clever, impressive or jaw droppingly awesome the code we write might be, if it isn't versioned, built and deployed correctly then all that hard work is for nothing.

In software engineering, SCM is concerned with tracking and controlling changes to the software. As such it is concerned with the following goals:
- Configuration control - impementing a controlled change process
- Version control - managing changes to the source code and programs comprising the application(s)
- Build management - managing the process and tools for building the software

When I initially became involved in SCM the tools I used were quite rudimentary. They consisted of command-line tools and scripts that connected to version-control-systems (VCS) such as Source-Safe to fetch the code, build the application and then deploy this to a file share on the network. They were triggered manually (usually by a member of the testing team). Whilst this all may sound very basic (and it was all very basic) the underpinning fundamentals of today's Continuous Integration (CI) and Continuous Delivery (CD) platforms are not much different. The key differences I have seen are the levels of automation, flexibility and integration in SCM tooling nowadays. It is now possible to do far more with less effort in less time.

My first steps into CI and CD came in the form of Cruisecontrol.NET in conjunction with Nant build scripts using Subversion as the VCS. This brought whole new levels of sophistication to SCM. Now whenever a developer checked in their code to the VCS, it would automatically trigger a build, which in turn which in turn could be deployed to a staging server. The build process could run unit tests against the code to ensure code coverage and that the latest check-in had not inadvertently broken something. The power and flexibility of build specific scripting tools such as Nant are staggering. There is almost no limit to what it can't do. On the CD side, these can be manually triggered by testers on an ad hoc basis. However, with the rise of Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) cloud environments, it is also entirely possible to deploy your newly built application to the cloud (for example Azure) for testing. You are only required to pay for what you actually use, so you only pay for the testing environment when it is actually in use by the testing team.

SCM is now an integral part of the software development process, and not something that runs alongside external to it. SCM is integral to today's software development process. With the rise of Agile and Agile based methodologies such as SCRUM and LEAN, SCM has seen many developments, particuarly where Continuous Integration and Continuous Delivery are concerned. Agile based methodologies rely on this level of SCM sophistication. With the right tools and infrastructure in place, there is almost nothing your SCM cannot do.

I have setup and configured entire CI and CD environments from scratch. This has included the already mentioned CruiseControl.NET and Nant (using Subversion), and more recently with TeamCity and MSBUILD (using Team Foundation Server). All of these are a far cry from the tools that got me started.

Althought the tooling that surrounds SCM may have changed, bringing whole new levels of sophistication to the software development process, it is reassuring to know that beneath all of this tooling the same core principles still hold true. Version control and build management are fundamentally unchanged in their core outcomes and processes.

"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

Microsoft have developed an open source web browser built with HTML, CSS and JavaScript as a Windows app on the Windows 10 platform. The full source code is on Github[^].

The new open source browser is intended to highlight the new browser rendering engine that ships with Microsoft Edge called EdgeHTML, which is what powers their new browser in Windows 10. To show how the new EdgeHTML engine can be used by developers, they have released an open source project demonstrating its use. This project is called Javascript Browser.

"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 received the email shortly before going on holiday offering to add my name to the list of people wishing to upgrade to Windows 10. So I dutifully responded and went on holiday the very next day. Upon returning I had received confirmation that I could proceed with upgrading to Windows 10. So naturally enough I did just that.

It was all perfectly simple and easy and I didn't experience any issues. The only problem I had was logging in for the first time after the upgrade. My password (which contains non alpha-numeric characters) was not being accepted. I soon sorted this when I realised the keyboard layout was set to US rather than UK.

I've been using Windows 10 now for a few days and am perfectly happy with it. If you already use Windows 8 then you'll already be familiar with the UI anyway, but there are plenty of other new features and apps to make life easier.

All in all a perfectly simple and painless upgrade.

"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 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

Dominic Burford - Professional Profile

Summary

Reputation

Privileges