// Richard Hart / Hates_

Archive
programming

Please don’t let yourself go stale

programming

I’ve written before about the notion of developers going stale. Day in day out I see examples of ydiw, but not of the “You’ve made a mistake, let me fix that for you” nature, but more of the “The 80′s called, they want their program back” type. I can forgive bugs and mistakes, but I just find it very hard to not get annoyed with antiquated and long-winded ways of doing things, especially when there are far better/easier/quicker ways of achieving the same goals with other tools.

Burying your head in the sand about different techniques and technologies does no one any favours, especially yourself. You don’t need to learn each new shiny language in depth or even at all, but just reading a bit about it or even trying it out will propel your game so far ahead of the pack that you’d be foolish not to do it. Now maybe you don’t care, maybe you’re just not interested and that’s fine, it’s not for everyone, but then don’t make others suffer because of your laziness/lack of enthusiasm. I don’t come over to your house and shit in your living room, so please don’t do it in mine.

It just pains me so much when I see things being done wrong. You can call me a fanboi if you want, but I don’t simply bang the drum of the technology I use because I’ve been brainwashed, but because I’ve been where you are now and discovered something better. Now you can always ignore my advice, after you’ve investigated it yourself, but don’t just dismiss it out of hand. So many people make out like it’s such a great sacrifice to try other technologies. But how long would it really take to try something? Not even a few hours. You’re not willing to give up a couple of hours for potentially days and days of re-couped time? Get out of here!

Finally, if not for yourself, do it for your clients. Would you trust a doctor who used methods from the 15th century? No? Then why should your clients trust you if you’re still using crazy old ways to get stuff done.

So let’s make the world a better place and make my life easier at the same time. Right, I’m off to play with HTML5 and CSS3.

Read More

It’s the polish that takes the longest

programming

After spending a few hours in Photoshop trying to get some buttons to just look “right”, I started to think about how I seem to spend the majority of my time adding “polish” to applications. Getting features in is easy, getting them working nicely and looking great is hard. It’s the 80/20 principle, it’s that final 20% that makes the difference between good and great. Apple is the obvious choice of reference here when it comes to polish. Their products are polished to such a high degree, that can’t help but I wonder what percentage of time they spend getting it right over getting it done.

Read More

who.removed.me

programming

I had the worst tooth ache last Thursday so couldn’t sleep. So while being up for most of the night I thought I’d whip up a small app to track my Facebook friends using the new Facebook Graph API. I’m always curious to see who has removed me on Facebook, and now I can finally see who has. Check it out here http://who.removed.me

Read More

What we all need is understanding

business, programming
There’s always that storyline in films and TV shows. Parents despair as they become more and more distant from their angst ridden teenage son/daughter who complains of just being mis-understood. There all the signs of neglect on the parents side, by not spending enough time/showing enough love, then there’s normally some sort of event that brings them all together again to be one big happy family. Think John McClane in Die Hard and his daughter Lucy, or Sean Archer in Face/Off and his daughter Jamie. The parents and the teenager are living separate lives and there’s a clash when they come together, because neither understands where the other is coming from.
As a developer one of the ways this problems often occurs is when working with people not from a technology background. Warren Buffett’s famous advice is to simply “Invest in what you understand.”. Many people take the time to understand their market, but do not take the time to understand the technology/process. It’s no surprise to me that the only company that I’ve worked for that’s actually achieved a measure of success is run by people who not only have a very clear understanding of their market, but also have a very clear understanding of the technology they provide. And what of the others that are no longer around? It’s no surprise I spent a lot of time at those places trying to explain how things worked and why things couldn’t be done. Yes, and while some businesses needs to be about pushing the boundaries and innovation, to do so also requires a knowledge of the limitations of what currently exists.
I have been as guilty of this sin as everyone else. As a developer it’s very easy to take no interest in the customer side of things and care only about the technology, and perhaps to a degree this is an even worse situation to be in over having management that don’t understand technology. When this happens solutions that are unusable by anyone can end up being delivered. I know for a fact I have delivered plenty of products without ever asking myself who the product is actually aimed at, all the while being feature focused. Where as now, rather then only caring if something can be done or not, I try and ask myself who will be trying to achieve a task and what is the best way for them to go about doing so. As with anything, there is a balance that needs to be found.
Managers, understand the technology. Developers, understand the market.

There’s always that storyline in films and TV shows. Parents despair as they become more and more distant from their angst ridden teenage son/daughter who complains of just being mis-understood. There all the signs of neglect on the parents side, not spending time with them or not showing enough love. Then there’s normally some sort of horrible event that brings them all together again to be one big happy family and they all live happily ever after. Think John McClane in Die Hard and his daughter Lucy, or Sean Archer in Face/Off and his daughter Jamie. The parents and the teenager are living separate lives and there’s a clash when they come together because neither understands where the other is coming from.

As a developer this problems often occurs when working with people not from a technology background. Warren Buffett’s famous advice is to “Invest in what you understand.” and while many managers take the time to understand their market, they don’t take the time to understand the technology/processes of their business. It’s no surprise to me that the only company that I’ve worked for that’s actually achieved a measure of success is run by people who not only have a very clear understanding of their market, but who also have a very clear understanding of the technology they provide. What of the others that are no longer around? It’s no surprise I spent a lot of time at those places trying to explain how things worked and why things couldn’t be done. And while some businesses are about pushing the boundaries and innovating, to do so requires a knowledge of the limitations of what currently exists.

As a developer I have been as guilty of this sin as everyone else. It’s very easy to take no interest in the customer and to care only about the technology. Perhaps to a degree this is an even worse situation to be in over having management that don’t understand technology, as when this happens, solutions that are unusable by anyone are usually delivered. I know for a fact I have delivered plenty of products without ever asking myself who the product is actually aimed at, all the while being completely feature focused. When I think back to those products, it’s a wonder they survived any sort of usage at all. Now, rather then only caring if something can be done or not, I try and ask myself who will be trying to achieve a task and what is the best way for them to go about doing so. As with anything, there is a balance that needs to be found.

Managers, understand the technology. Developers, understand the market.

Read More

Broken Window Policy of Programming

programming

There comes a point in every software projects life where everything just feels wrong. No one wants to touch the code as it stinks and everyone working on the project just feels demotivated and would rather just go home then have to do anything more on it. On projects like this, when it comes to adding new features or bits of code, because everything else is such a mess, the changes are just hacked in rather than being properly thought out and coded up well.

We’ve all been there and the frustrating thing is that our opinion of the project, from good to bad, seems to happens over night. If you sit down and think back, you can probably pick out all the things that were just shoved in that eventually led to the project becoming a mess, but at the time we never chose to do anything about. It’s almost always a case of deferring better solutions or a round of refactoring to some point in the future. “I’ll knock this up now and come back to it later.”. The problem is that later never comes. This is the essence of technical debt. You may only go into debt by a fraction, but do it a few times and eventually all those fractions add up. Until one day when you go to check your balance, you find yourself swimming in the middle of the ocean with no land in sight.

Implementing a broken window policy can go a huge way towards keeping a project healthy. If there is a broken window (bad code) fix it as-soon-as-possible. It doesn’t have to be that instant (although if you can, you should), but fix it. Part of the policy also means trying not to break windows yourself. Write the best code you can, as often as you can. Set the benchmark of quality for the rest of the team, even if they don’t follow suit. The danger is that many people are very “me too” about things. “Well if such-and-such can do it like this, then so can I *hack* *hack* *hack*”.

Of course we all write crap from time to time. TBH most of the stuff I write is crap. But I honestly feel more motivated to work on code that’s been loved and looked after, rather than something that’s hanging together by a thread.

Read More
Real Time Web Analytics