Science cont...

Previously I stated that I believe the scientific method to be our best bet on determining the validity of a claim. However, I also stated that I believe scientists to be flawed in their implementation of the scientific method. This is partly because no-one is truly independent, especially when it comes to disproving their theories. It is especially true when it comes to money, determining your own career and keeping your job.

Richard Dawkins

When I was at school I read The Selfish Gene by Richard Dawkins and changed my plans on what I wanted to study at university. One particular story from the book has stayed with me throughout my life - it was about a Cambridge professor who sat in a lecture given by someone with an opposing view point. The professor realised that the opposing view point had great merit and at the end of the lecture he went onto the stage, stated he had been wrong for a number of years and thanked the lecturer for correcting him.

Like most people, I have spent much of my life being wrong and being corrected by others, but that story has always helped take the sting out of it. It is much more important to learn than it is to be right.

Big science

I fear that the large sums of money being poured into science and the way it is handled has caused this lesson to be lost in science today. This is because it's pretty difficult to take £150 million in government money to study the nuclear furnace in suns and then turn round and say "sorry, I was wrong, it's all based on electricity".

In the introduction to his book The Trouble with Physics, Lee Smolin talks about the difficulty of getting a tenured professorship in particle physics if you don't study string theory. Donald Scott talks about NASA (annual budget of $15 billion tax payer's money) openly refusing to fund any cosmological research that is adverse to the Big Bang theory. Rupert Sheldrake talks of Richard Dawkins refusing to listen to his evidence before debunking him.

Yet every new major discovery in science has brought with it things that were previously unthinkable, for example, Bruno's assertion that the sun was a star, or Darwin's assertion that we all have a single common ancestor. New discoveries often prove the old ideas wrong - the earth is not flat, nor is the universe mechanistic. Yet science is closing down alternative avenues of investigation to concentrate on the most popular?

This dogmatic approach to learning seems far removed from the early writings of Dawkins that so spoke to me. It also seems somewhat counter to the general spirit of scientific discovery, especially when Rupert Sheldrake asserts that if a mere 1% of the current scientific funding could be used to fund non-mainstream projects and make a real difference.

We are living in a time where advances in particle physics have slowed dramatically. The imagined benefits of the human genome project largely failed to materialise, despite enormous amounts of money being thrown at the problems. Perhaps it is time for science to become less dogmatic, less like a religion and more like an open network of people searching for answers through rigorous application of the scientific method.

Science

One of the problems with interacting with others is dealing with a fundamental lack of common ground. For example, when your two view points on a topic of discussion are so far apart that there is no place to plant a flag and say "Ok, this is our mutually agreed and understood starting point". I find that these are always deeply painful discussions, which sadly are usually quite difficult to get out of. This can be pretty depressing, as they also seem quite easy to see coming.

If you are a musician, one such conversation may start "I don't see what all the fuss about jazz is, I mean, it's just picking a series of notes from your scales isn't it?" Obviously, when someone says something like this as an opener, you can just let it slide, but when they wait until half way through a discussion, you can't really just nod and smile.

Scott Adams (of Dilbert fame) has pretty much made a living from these kind of fundamentally opposed understandings in engineering. I once had a supervisor say to me "I don't understand why this is taking so long, if it's a computing problem, then the answer must be either zero or one. Just try them both and use whichever works." I still wonder if they were actually pretty funny and I just didn't get them.

It is perfectly possible for two people to view the same issue very differently and for both to have sensible views. Politics is full of such scenarios, however these are not the issues that concern this post.

For me, these interactions often start part way through a discussion with the assertion "well, 'Science' doesn't know everything". This statement tells me a number of things:

• My assertion that I am right in this instance has been extrapolated to an assertion that I am right about everything.
• The discussion has moved to an emotional phase
• There is evidently a deep misunderstanding about science.
• If I haven't been able to explain my point up until now, there's no chance of me doing so by continuing.

Science doesn't know everything

Science doesn't know anything... it's not an entity in its own right. There are scientists, who certainly don't know everything and as far as I am aware, they don't claim to. In fact, if ever there was a group of people who are crushingly aware of what they don't know, it's scientists. Scientists are a group of people who attempt to acquire knowledge in a systematic manner. That systematic manner is called the scientific method.

The scientific method

The scientific method is the best method we have for acquiring knowledge. Its past victories include penicillin, television, brain surgery, space travel and the atomic bomb. It is of course flawed as are the people who implement it, however it still remains, to date, our best bet for determining the validity of a claim. So, when Brian Cox appears on tele and tells you that the sun is a giant nuclear furnace, he isn't handing you down a decree directly from science itself. In much the same way, when I say "there's no evidence to show that homeopathy works any better than sugar pills and no obvious method through which it could have the effect you are stating" I am not saying that I know definitively that homeopathy is a load of crap. I am saying that there is no evidence at all to suggest that it does work and thus, it would be foolish of me to believe it did.

I am not saying that it is impossible that I have won £2,000,000 on the Spanish email lottery; it's just that it would be foolish of me to believe something without real, compelling evidence.

It's the same with homeopathy. I would gladly take homeopathic remedies, if someone could give me compelling evidence to show that they worked. It's not enough for me to hear that a friend's aunt took this potion and she swears by it, I want to see it work in a standard and repeatable manner.

Being right for the right reason

It is also important to be right for the right reasons. Being right for the wrong reasons are just luck and that is a poor strategy for future success. For example, lets say you have 2 boxes, one has £100 in and the other is empty. You can choose one box and keep its contents. The only information you have is that the box on the left is twice as likely to contain money as the the box on the right.

There are four possible outcomes depending on your choice and the location of the money:

	Left box chosen	Right box chosen
Money present	You are lucky and smart	You are lucky and an idiot
Money not present	You are unlucky and smart	You are unlucky and an idiot

My point here is that the result depends on how lucky and how smart you are. However, you can only affect how smart you are.

Developer Cruft

Like most developers, when I start to work on a new project I don't generally do so from scratch. I have a series of code snippets I use to do common tasks. Things which can be added to a project quickly and safely - having been tested in the fires of other projects. This helps me develop faster and more robustly - it would seem growing old has some upside. Experience counts for quite a lot in development. Having a back catalogue of problems you have experienced and solved is very useful.

However, software development is a fast moving industry and I can see a trap waiting for me. Anything I wrote previously could have been superseded by others in open source projects. Unfortunately, it is much easier to use a familiar block of code than to learn something new... This is not a problem a more junior developer faces, there is only the unfamiliar. The code produced may take longer, but it perhaps has the advantage of being more relevant. My name for this issue is developer cruft, how much of my code at any one time is a bit old and past it?

My solution to this problem is to look toward peer review, having others dig about in your code and make fun of it is a great way to get to grips with new things that you've missed. Sometimes that's not really possible, for example, in a really small team. When you are on your own, it's hard work keeping up to date. The recent explosion in JavaScript and thus JavaScript libraries, frameworks and plugins make it hard work keeping up-to-date. I find reading other people's JavaScript a great way of getting development advice from others - sure it's harder work, but its really helpful. As well as reading other code, working with other code can be a real eye opener - if a project isn't highly time pressured, consider developing in a different manner, perhaps using a new framework, it will open you up to learning and that's never a bad thing.

Don't get me wrong, code doesn't become bad simply by getting old. Sometimes the code you wrote a while back was awesome then and still rocks the show today. Sometimes it was sub-optimal then and you've learnt enough in the intervening time to recognize and fix it. Whatever you find, its important not to rely too heavily on old code you wrote when you were less experienced than you are now.

Opinionated Development

Opinions

I am a big fan of opinions. I hold my own quite strongly and I like others who hold their opinions based on experience and good sense. Opinionated development seems like a winner then, things which have been learned from experience becoming standard methodologies. Obviously, this is only really useful if you agree with the opinions of the creator. However, it really shines if you are inexperienced and looking towards others for good practice. Encouraging good practice is a worthy thing, it is often hard to find good information when writing software and it is impossible to avoid problems you are ignorant of.

Arguments

Obviously, there's a "but" in there somewhere... I do like opinions, I also quite like a good argument. I find having my opinions challenged good fun and also quite enlightening. The best people to challenge my opinions are those with different experiences to mine (as well as greater knowledge of the subject matter!). Whereas I may have avoided a technique due to inherent issues, others may have found ways of neutralising the issues rendering the technique useful again.

Communities

A possible pitfall that I see in opinionated development communities is that they will tend to attract like-minded developers. Penetrating discussions rarely occur between people who agree on a subject and there is a possibility of the community becoming dogmatic. Especially when junior developers learn their trade in this manner, with no direct experience of the value of other methods.

Just a thought...

Choosing a library / framework

As I may have mentioned, I'm working on a javascript web app at the moment and it's been pretty interesting. We're taking a restful approach to the system and maintaining as much separation between front and backend as possible. One of the first decisions I had to make was whether or not to use a framework to take care of that side of things for me. I really like backbone.js and was struggling to think of a reason not to use it and build something myself. Obviously building something from scratch would help me develop my skills and be a great learning experience, but would it suit the project? Here's my initial thoughts on the subject.

Pros of using backbone.js

It's well written, proven and much better tested than anything I could build in a reasonable space of time. It follows a tried and tested route for developing the type of web apps I was looking for. Working within the clear confines of the library would help to speed up the development of the app. It would also speed up on-boarding of new members of staff faster than having them learn a custom framework first.

Cons of using backbone.js

The framework won't be mine, I won't know it as well as something I'd written myself. I will have to work around the differences between a generic framework and my specific needs. As we are developing the application in an agile manner, it's impossible to know if the framework meets our, as yet, undefined future needs.

Initial Conclusions

Yea, this all pretty much adds up in backbones favour, doesn't it? Using a generic framework would be faster and would help keep my code from becoming a sprawling mass. The smart thing to do would be to immerse oneself in backbone and really get to know it. My only remaining doubt was about the actual needs of the system we were building.

Further thoughts

There was still that nagging doubt in my mind though. How could I learn a new framework and expect it to keep my code neatly organised, when what I needed my code to do kept changing and morphing as we worked on the user journey? I was busy thinking about how I couldn't build something as polished as backbone in a short space of time, when it occurred to me that perhaps I didn't need to. Building a framework that was specific to the apps needs as they grew and developed might actually be faster, as changing my own code is easier than changing directions within a new framework. It also occurred to me that my framework wouldn't need to be as good as backbone - like everything in commercial software, it needed to be adequately good. Especially as I expect the code written in this early "let's get something online as quickly as possible and refine it as we see how people use it" stage to be re-done at some point when the system requirements are more fully understood.

This new idea had other benefits too. By building and developing the framework to the applications growing needs I would have a much better understanding of the system. Later on, when the app was more mature, it would be much easier to put it into a generic framework like backbone.

So far, it's been an amazing experience. I've learnt a truckload and really enjoyed it, the app works well and seems pretty solid. I also feel like closer to the system, it's my code, I know which bits are optimised and which bits aren't. I also know exactly how long it will take to change the areas that need to adapt to user requirements.

I am happy with the decision I made and the results we've had. I know so much more about how the app should work that I would do a much better job of putting it into a framework. I still have plans to do that, but I have more to learn about the system first.