Category Archives: work

Investing in Your Own IT – The Ultimate No Brainer Pt. 2

Written by Richard. Posted on October 22, 2008. Filed under annoyances, computing, work. 1 Comment.

This is a follow up to my previous post about investing in your own IT. The more I think about the more I keep coming back to the thought that it’s not about investing in IT, it’s really about investing in your people. After all, without your people you’re nothing. Yes, without your people you are nothing. Zilch, nada, zero, nil, null.

You’re not spending money on new computers so that tasks are done faster or made easy to achieve. To claim that is to say that the key to success lies within the tools. It doesn’t. It lies within the people. “Well”, you may say, “then it doesn’t matter what equipment I give them then!”, and with that you would join the many number of managers I’ve heard say the exact same thing and who I believe had no a clue as to what their people actually did. Good tools do not create good developers, but bad tools do create bad ones. And I don’t mean bad in the sense that all of a sudden they start writing bad code, but that they become de-motivated, uncaring and uninterested in their work, to the point where it has a significant impact on their deliverables.

Now you could say that a developer worth a dime will rise above and make best with what they’ve got, but we’re a proud bunch of people and of course want nothing more than to do good. But if you begin to even start to feel like you’re being set-up to fail or that you are not important, then it’s lights out and that is going to have a major impact on your motivation and which will affect anything that you are supposed to deliver. A motivated developer will always create something faster, better and stronger then one that isn’t. A motivated developer is a productive developer.

“Hey, I’m paying these monkeys! So they can just lump it or get the hell out.”

Well at least you are brave enough to admit that you’re paying people to put up with your shit. But why? Why be shit? Isn’t there some part of you, deep down, that just wants to blow the fuck off the roof and do extraordinary things? It all comes down to self-development, whether that be the self as an individual or the self as an entity, like a company. I touched very briefly on the subject in my post about typing, the short of it being, if you have the opportunity to improve, why would you not do it? There are, of course, reasons not to. Perhaps it’s fear. There is the fear that if you make the effort to try, that you will fail and others will laugh at you, or there is the fear that the actual process of trying to improve will only expose your flaws, and no one one wants to be exposed as being a complete moron (You know who you are). Perhaps it’s monetary. To get better, you may need to buy new equipment, new materials, go on courses, whatever. It’s easier to steer the course then it is to make waves. There are always reasons not to do something, but does that mean we shouldn’t do anything? Of course not. Let’s give our developers a moral boost. Let’s motivate them. Let’s make them feel important. Don’t stick them on shitty machines with small monitor/s.

Fuck it, where’s my new machine?

[Flowchart modified from the Panflute Flowchart]

“It works 60% of the time, all the time!”

Written by Richard. Posted on October 16, 2008. Filed under annoyances, computing, work. No comments.

You can’t get a little bit pregnant. – Lou Mannheim

There’s a story about a manager that said his team was doing scrum/xp. When pressed as to the details of what that meant, the manager replied that they were doing ‘no documentation’. Scrum is the in project management methodology of the moment. Quality? Scrum! Clear deliverables? Scrum! Happy developers? Scrum! Pole dancing midgets covered in maple syrup? Scru… Hey wait a minute!

So yes, Scrum and what does it have to do with getting a little pregnant. My point is, if you’re going to do it, you need to go the whole way. It’s not enough to just dip your toes in the water. You may refer to your current load of work as a sprint, refer to units of work as stories and may even refer to your working capacity as your velocity. But, scrum is not about giving names to concepts, or about having a backlog, or having a burndown chart etc. Even if you did all of theses things together, you would still not be doing Scrum, because it is more then the sum of its parts. And I can guarantee you that if you start going down this path of faux Scrum, when things start to move slightly off course and panic starts to creep in, you’ll dip into your old ways to “fix” the immediate problems and then when the shit really starts to hit the fan, you’ll give up on it completely and deem the whole exercise a failure. That’s why you can’t get a little bit pregnant. You’ve got to go all the way and get to fourth base.

“Woah, Joe, all theses companies are succeeding with Scrum, we should do it too!”, “Yeah lets!” – High five! The product backlog gets written up, the burndown chart gets drawn and every morning there’s a stand up meeting with some people to discuss ‘work’. A week or two goes by and it really starts to feel like the wheels are greased and progress is being made. Then an urgent client request pops up, a massive bug has been found, or that feature they asked for two months ago and which they’ve just seen (Hey, we’re retrofitting Scrum to primarily waterfall driven project), isn’t what they wanted. Well the request is fine, we’ll go through the current sprint’s backlog with them and they can decide what they would like pushed back. Oh, they don’t even know what a sprint is, “What did you say? Spinelog?”. Well the bug is not a big deal, we’ll just run our tests, make the amends and get it sorted real quick. Oh there aren’t any tests. Ok well at least the incorrect functionality we can handle, we’ll just plan it into the current or next sprint and continuous integration means they can monitor the progress as we go a long. Spontaneous combustion? Fuck me. It’s not good enough to pretend, or for the development team to do it in isolation from the stakeholders or customers. To succeed you need buy-in across all the people involved with bringing the project to fruition. Everyone needs to understand the process and understand the role that they play. Pretending to do it ends up giving the team (mostly management) a false sense of security and that can really come round to bite you in the arse.

Don’t get me wrong, I’m not saying that doing Scrum in the above fashion is always wrong, because sometimes your circumstances leave you with little choice. But, what I am saying is that proclaiming to be doing Scrum without understanding it all the while living in blissful ignorance of the flaws of your own processes, is bad and harmful. I don’t mind mistakes or doing things the wrong way when you start out, because really you need to start walking the path before you can get to where want to be. I just can’t stand people saying their walking the path when really their just sitting on their fat arse, biding their time.

Man looks into the Abyss, and there’s nothin’ staring back at him. At that moment, man finds his character, and that’s what keeps him out of the Abyss. – Lou Mannheim

Investing in Your Own IT – The Ultimate No Brainer

Written by Richard. Posted on October 7, 2008. Filed under annoyances, computing, work. No comments.

I’ve been cursing my work computer all morning and am once again considering either bringing in my computer from home or just buying one outright (It wouldn’t be a first. I paid for my own monitor here at work. Go figure). Kris Kemper wrote a good post on the subject a few days ago.

I’ve seen this on every project I’ve been on. We are given slow machines, and time is lost. It may be lost because I’m running grep over a lot of files, it may be because when I have my all my development tools open and the machine slows down.

To me, when you’re in the business of developing software, investing in your own companies IT is a complete no brainer. Companies are normally extremely quick to spend on server hardware, but when it comes to development machines, spending is often few and far between. My machine here at work isn’t a “horrible” machine, but the agony it puts me through makes me feel that it’s perhaps not best suited to the task of developing on. But then even simple tasks seem to thwart it with constant disk grinding. I tried deleting an old repository checkout, no more then 200mb on the disk, and stopped it after it had only reached 14% done in 10 minutes. Virus checking my update of DirectoryOpus took nearly 3 minutes. Maybe it’s just a build issue and not so much a hardware one. Vista complains that all off the Office 2007 apps are not valid Win32 applications or the Snipping tool politely tells me it’s not working “right now”. Yes, I can see that. Whatever it is, it’s not the sort of shit that you need when you’re in the middle of something. Whatever, they should have got me a Mac.

I can understand that sometimes you just can’t afford whizzy machines or the latest version of software. Just don’t let me catch you running a .NET stack and complaining about not being able to afford machines fast enough to run it.

CSS Mastery

Written by Richard. Posted on August 26, 2008. Filed under computing, programming, work. No comments.

I have always hated CSS simply because anything I ever did would break in either Firefox or IE. I would spend countless hours tweaking and experimenting to get things consistent, and even then it felt like things where hanging together by a thread. Once things worked, I prayed I never need to “change” it. I have to confess that up until recently I still believed that tables were the solution to most web UI problems. A table here or there never hurt anyone. Really though, tables are sooooo Altavista. Thus, I’ve been making a conscious effort to move towards styled divs without tables full of spaced out cells containing transparant spacer gifs. I have been pretty much fudging my way through it so I thought I should read up on the subject and saw that CSS Mastery had gotten some really good reviews. I stole the office copy, made my way through it and can honestly say, with hand on heart, that it is an absolute must read for anyone involved in any sort of web development. My CSS ability has developed by leaps and bounds. I recently put together our new site which gave me a chance to flex some of my new found CSS skills and it made such a difference. Everything came together quickly and painlessly. For the first time ever I had a site that worked in both Firefox and IE pretty much off the bat and I had a tidy HTML and CSS file. Will this book make you a CSS Master? Probably not, I’m not one yet, that’s for sure, but it will get you on the right track to eventually getting there.

To go off on a bit of a tangent. Some work places have a specific team that do all the styling and formatting of whatever the developers give them. Maybe on huge projects, it makes sense, but in small teams I see no benefit apart from massaging the developers own egos and beliefs that HTML/CSS is beneath them or something. This divided approach really bugs me, simply because I believe that it causes developers to not give the asthetic or functional side of what they produce any consideration. Un-usable? Hey, it works and that’s all that matters, it’s not my job to make it look pretty! The process is circular. Good design begets good functionality begets good design begets… You get the point. Design is not just about making things pretty, and that’s the trap that people fall into. It is about communication; giving the user an experience they understand and can relate to. I’m not a UI guru or claim to have all the answers, but I’m a big believer in at least trying. The curse of knowledge from the book Made To Stick plays a big factor in this. People find it extremely hard, if not impossible to imagine not knowing what they know, and that is what stifles communication. I once argued with a company director about an existing system’s poor UI. They claimed that it was sooooo easy and quick to use and I pointed out that’s because had been walked through it so many times and used it nearly every day. So eat your own dog food and do your own HTML/CSS. Use your own system and pretend like you’ve never used it before. Do a hallway test and ask someone to perform a task without telling them how to do it. You might be surprised by the results.

Career Advice

Written by Richard. Posted on August 6, 2008. Filed under books, work. No comments.

Don’t know know what the hell you’re doing with your career? Read The Adventures of Johnny Bunko. Career advice in the form of a manga. Should only take you about 20 minutes to read (More if you’re slow like me).