A thought on creativity

The best collaborative environments I’ve experienced are the ones full of creative people. Creative people like to create things. Both for themselves and for others. Doing that gives a sense of pride in what they build. Collaborating with others enhances that and leads to an environment where things get done quicker and better while enabling collaborators to learn from each other and in turn develop themselves. Fostering creative thought leads to knew ways to solve old problems and solutions to problems we haven’t yet encountered. When people work and play in this way it’s the best environment to be in.

Understanding what the Minimum Viable Product is.

Here’s a great article on understanding what the MVP is. So many people seem to want to finish a project without any sort of iterative release process and just go head first with one massive release.

As I have worked on more projects and gained more and more experience of the release process and gathering valuable customer feedback I can no longer imagine releasing a product to a customer base without having prior feedback through releasing small chunks of functionality at a time.

Working in an agile way helps you to work with shifting requirements and customer expectations without leaving the customer feeling like they’ve been ignored.

File Uploads in Laravel 5

I started using Laravel recently and I love it. Every day I spot something awesome about this framework.

Image uploads are so straight forward in Laravel.

In your view you can have a file field like this

<input type="file" accept="image/*" name="image" id="image" class="form-control" value="">

and in your controller you can handle it like this

$uploadedimage = $request->image;

That’s pretty obvious. But what I discovered tonight is that $request->image which refers to the image key in your request object returns an UploadedFile object automatically. This means you don’t need to cast it or anything. It’s already the right object and as such you are ready to work with the image file using the methods on that UploadedFile type.

if ($uploadedimage->isValid()) {


Developers. Ever the Optimists.

We’re always the optimistic bunch. Ask a developer how long it’s going to take to build something and they’ll throw back an estimate without second thought. Why? Because we always assume we can do it without problems. This is never the case. And the problem with estimations from developers is they tend to always lean on the optimistic side. We never think about the possibility of bugs or scope creep or requirements changing and all the other variables that you know might pop up but it’s always going to be ok…

The worse thing about it is that we always do the same thing over and again. We never learn. So I’ve been trying to change the way I look at jobs. With experience it is possible to begin to think pessimistically about jobs. That sounds awful. But it’s beneficial. Ask yourself, ‘what can possibly go wrong?’. Then start thinking about how likely those things are. Start looking at who is asking you to do some work. What is their history like when it comes to scope creep or changing requirements? Are there people in the background that you don’t have a direct line of communication with that are maybe influencing what they see as necessities when really they are just nice to haves. Have a look at your past work. How often have you had things come back because they were not quite right? Have you learned from previous mistakes in workflow and deployment strategies? Are you still using old techniques, ageing frameworks or development tools? How much other work have you got on? It’s very easy to take on a job because it’s hard to say no and then ending up in the mother of all bottlenecks. You promised one person you’d do something in a week and you promised another person you’d deliver that refactor in a day. But then you forgot about a deployment just around the corner or a website migration from one really bad hosting company to another equally bad hosting company which your client insists on using.

We’re also always afraid of rejection. If you give an ambitious estimate it might look great for a week or so but then those false expectations become a bit of a problem when it is evident you’re not going to meet your own deadlines and fulfil your commitments. Actually being conservative in your estimation will often buy you a bit of breathing space and you’re client is probably going to be more appreciative than if you were constantly pushing back ETAs on your work. A conservative estimate can always be refined. Finishing something earlier than expected gives a great mental boost and your customer will love being told that they’re product is ready before they expected. The opposite isn’t so great.

It’s all about breathing space and anticipating that things might and will probably go wrong at some point in the project. Not giving yourself that space means that when things do go wrong something has to be sacrificed. You don’t want a domino effect where other projects end up in the firing line because an unrelated project suffered from a setback.

There is also a lot to be said about the refinement process. We often find that backlog items creep up on us. Items that you might have estimated at a high level a month or two back but now with some experience you know that the estimate is wrong. You need to tell the customer as soon as possible. Unfortunately it’s too late and you’ve put yourself under pressure. Refining your backlog is great as long as you make time for it. Revisit all those jobs that you have lined up and ask yourself if what you’ve been doing lately is going to impact those jobs. Whether negatively or positively any impact needs to be relayed to the customer as soon as possible. Being able to give your customer the realistic expectation is critical. They might have other jobs that rely on your estimation. They might have marketing material scheduled to go out on the day you said this project would be finished… that estimate from 2 months ago might be costly in more ways than one.

Profiling MySQL

Forgive the note format of this post, I’m currently reading High Performance MySQL 3rd Edition and making notes here as I go through it.

For PHP applications:
– New Relic
– xhprof
– xdebug
– Valgrind
– CachegrindIfP

– mysqli_x (automatically instrumented)
– Perconna Toolkit
— pt-sift
— pt-mysql-summary
— pt-summary
– configure the slow query log to capture all queries, pt-query-digest to analyse the log
– the general log can also be used but is less useful
– SHOW STATUS command after executing query to look at various counters
– Performance Schema in MySQL 5.5, shows waiting times for different stages of the query execution
– Show Global Status
– Show PROCESSList
– Show INNODB STATUS for server load, spikes in threads_connected
– Poor mans profiler

– mod_log_config

– tcpdump

Think Defensively

Defensive programming helps solves lots of problems before they even appear. It also means removing assumptions from code.

One way to think about it is being extremely paranoid. When writing code try to look at it in a way that makes you think ‘What would happen if this fails?’. Or ‘Should I assume that this is always going to be the case?’. Also, ‘What happens if someone unfamiliar enters this area of the code base. Is the code that appears obvious to me also obvious to the new developer?’.

Here is an extremely simple example.

public function analyseThis( $innNumber ) {
 if ( $innNumber == 1 ) {
  return 'one';

 return 'two';

Now, in my opinion there is plenty of scope for bad things to happen here. Firstly, as a programmer I might be wondering why ‘1’ deserves to be treated explicitly when ‘2’ isn’t.

Secondly as a developer I’d be wondering why if the number is not ‘1’ should I want to return ‘two’ if $innNumber is ‘5’.

Lastly and perhaps least significantly for me the code would be easier to read if we treated both equally and re-wrote the internals like this:

public function analyseThis( $innNumber ) {
 if ( $innNumber == 1 ) {
  return 'one';

 if( $innNumber == 2 ) {
  return 'two';

 return 'unknown';

This is a pretty simple example and perhaps a little too simplistic but consider a method that expected a number that could be anything between 0 and 1000. Then you’d have a bigger set of if conditions.

A more appropriate way to write this would be as follows:

public function analyseThis( $innNumber ) {
 $aNumbers = array( 1 => 'one', 2 => 'two' );

 $sStringVersion = isset( $aNumbers[$innNumber] ) ? $aNumbers[$innNumber] : 'unknown';

This way we don’t have the overhead of going through each if statement when we can directly access the keys value in the array, and if we don’t get a result we return a default ‘unknown’ string;

Some people reading this might be wondering is this not overkill in this example, we know we want either ‘one’ or ‘two’. Sure. But the benefit that we have here is that should this method grow in size and complexity we can at least be certain that we don’t return an incorrect string for when a new developer passes in a new value to the method.

Making assumptions in code is dangerous. It’s like saying that nothing is every going to go wrong in the code because everything you do is perfect and no one can tell you better.

Making the assumption that something as user is trying to access belongs to them is a dangerous assumption but one that is quite common. Assuming that someone has permissions or is requesting permission for something when in fact they are attempting something else is also a dangerous assumption. Assuming that the hardware infrastructure is sufficient enough to handle a spike in traffic when rolling out a new piece of software or functionality is also dangerous.

Writing unit tests will help you become more defensive. When you look at the code as an outsider and in a critical fashion you start to identify areas where conditions happen and write code coverage to test for those conditions. By identifying and recognising areas where there is scope for unexpected behaviour both in sofware and hardware helps to create solutions to problems that haven’t had the time to leap out and bite you on your arse.

What has Agile become?

This is an interesting article on The Register about the Agile development process.

The only problem I have with ‘Agile’ development is that it’s not really that Agile but that is probably down to my own experience. And even then it seems to be completely objective. Everyone seems to have differing views as to what an Agile development process actually is. And it becomes such a headache that what aught to be an agile environment can often end up being quite stifling. For example, I quite like having requirement specs. Why? Because for me they offer an end point for a project. A set of rules that can be developed in code and tested both through automation and quality assurance and also through unit testing. Some argue against requirement specs and suggest that the requirement is to just get something to work implying that requirement specs are some how anti-agile.

That is quite tempting but from experience what this leads to is developers coding things how they perceive that functionality to work, while product managers often have a different idea as to how things work normally based on end user perspective or how the marketers have sold a product . This causes issues for the developer and normally leads to developers asking test teams how the functionality should operate which is backward in my opinion. Developers need to be confident that they understand what they are coding, testers confirm that and the product managers communicate expectations to development teams via development managers. But in order for that chain to work effectively you need good communication.

Personally I think there are some aspects that can be taken from an Agile process and mixed up with more traditional approaches in order to strike a balance. I love engaging face to face with other developers and project stakeholders. It’s a great way to keep up to date with what other people are working on. I’m a great supporter of stand-ups, but not such a fan of irrelevant discussion or mini-meetings being held in the confines of the stand-up. That just wastes time and is frankly borderline rude.

And I love just getting my head down and coding. but I’ve also learnt to understand the value in testable code and taking the time to write tests to achieve a good standard of code coverage and object abstraction as well as good design. Moving fast and breaking things sounds quite sensational. I’m not sure I’d feel comfortable doing that if I knew I didn’t have some sort of test suite behind the code to alert me to issues caused by refactoring or feature development.

I love the idea of rapid prototyping concepts but I don’t like the idea of rushing out new concepts before the code behind it is mature, tested and proven to work. If you’re  a business that makes money and you rely on customers using your product then a ‘release now, fix later’ attitude probably isn’t the best way to go about showing how seriously you value your customer base.


I like a good amount of documentation because I think it’s valuable for new developers who come on board a project, for technical support folk and also for existing developers moving between teams.

Things I really don’t like are having to learn a new tool for managing sprints or code reviews when there are also tools and processes already in place. Anything that gets in the way of what developers should be doing. But I can also see how this can happen when different teams use different processes due to personal preferences of those who lead development teams.

I’m pretty sure that there isn’t a one-fits-all solution. And I’m pretty certain that there isn’t meant to be such an end point. But what I am sure about is that some principles when applied correctly can lead to great progression in a developers skill set.

I remember one of the first development jobs I ever had operated on a release now fix later principle. We were putting out products every week. Design decisions were left to the developers and features were implemented in ways that the developers saw best. Changes in functionality were made continually until the people in charge felt it worked better. The amount of time that was spent changing things based on design by committee seems quite scary now that I think back to it. Today I’m not sure I could ever imagine working in that way again. Being able to develop in confidence supported by great communication between technical and non-technical team members as well as open communication with customers really has opened my eyes to the way I work now compared to the way I used to work before.

Definitely read this article by Nic Ferrier, In Defense of Agile.