Wednesday, February 27, 2008

Training

Let me start with, I love my company, and am very happy where I'm at. I wasn't always that way. At one point in time there were major problems there. And many of those problems started with training.

Training was considered an "after you need it" item at the time. If we purchased a new technology, or already decided that we were going to do something different, then and only then would a few select individuals get to go to training. In the department of about 30 developers, there were maybe 5 that were getting to attend training or a conference every year. It was always same people, and everyone else was left out. Those few were then expected to return to work and pass on their newly acquired knowledge to the rest of us.

The list of things wrong here is long. The rest of us felt left out, mad, heck - flat out pissed off. We didn't understand why we were never allowed to go to training. We didn't understand why training was only after the fact. IT is a fast paced world, and you have to be ahead of the curve on training or you fall too far behind.

We built business cases for why training was good. Found studies on the internet to support our reasoning, and submitted it. Only to find out that no, we weren't getting more training.

Then there was a changing of the guard. A new boss came in. He walked into a company with a lot of people complaining about a lot of things. One thing he really supported though was training.

Since that time the training budget has gone up a lot, training is available to everyone now, and we get to choose what to go to, not go to something after the fact.

Training has been a huge moral booster the past 2 years, and it's helped improve skills. Being able to go away to training and learn something, then come back and apply it is exhilarating, and exciting.

Coming soon a series on tools and processes.

Several years ago a group of developers at work got together and came up with some ideas of things that could make the developers in our department more productive and the process better.

We had a list, which I can no longer find, but I remember several items.
  • A code library
  • A forum
  • A knowledge base
  • Business Analysts
  • Code Reviews
  • Cross Training
  • Training
Over time we implemented all of these, and have stopped some of them for one reason or another. Over the next several posts I will address the reason we wanted these, along with why they did, or didn't work.

Monday, February 18, 2008

Testing on an island

I read Derek Whittaker's post the Sound of One Man Testing, and it got me thinking to the first to adopt people. The ones that read incessantly and find the hints of good ideas and do what they can to introduce new concepts into their work. These people are the ones that figure things out, and solve the hardest problems, they go the extra mile all the time.

I got to thinking about unit testing at my own work. About 3 years ago I had just heard the concept of test driven development. The few paragraphs I read about it sounded interesting, but I couldn't quite get my head around it. I didn't understand why I'd write a test for every level of code, when an integration test would take care of all of it. This just didn't make sense to me. I like to pride myself on being one of those early adopters. I'm not on the bleeding edge, but I do what I can to read about things and stay up to date at least on the concepts for things. Test Driven Development is a huge concept, with great benefits and I couldn't quite get it. It took me a reading a couple of books and writing a project with test driven development before I started to get it. Yes, after a fully TDD project I only started to get it. Even at that point I had done things wrong. Mocks were still a mystery and I hadn't found any good tutorials. For the first time I felt like I needed my hand held as I walked through something new. It was scary.

When it comes to work I tend to be fearless and take on any challenge given to me. But this was different. So for those early adopters that are out there trying to be the person testing on an island and starting it in your company. Remember, even for some of those who tend to lead, it can be hard. If you work in a place where you do have some small 1 man projects I recommend using one or two of those as proof of concepts for TDD before even attempting to insert it into a larger project. Talk to your co-workers about TDD. Send them blogs, magazine articles, books, anything to make TDD a topic of conversation. And then, offer to hold their hand. Show them with in-house training, led by you. Teach them about mocks and dependency injection and why you have to use them with the design in order for the unit tests to be black box. Explain black box and talk about all of these concepts, which are very likely new concepts to a team that is not already doing Test Driven Development.

Finally, start adding tests to a large project that you are working on. Offer to help your co-workers build their tests.

I've been reading about TDD for 3 years now. Currently I'm working in Java and I'm comfortable from the bottom layer all the way through the web service layer in writing tests, but I still don't know how to test the GUI. Even after 3 years there is still a lot of room to grow in my Test Driven development. And if you are thinking of starting Test Driven Development, don't look at this and think that it's too hard. It's not, and the quality that you gain in the layers that are tested is great. The current project I'm working on is closing in on 1,000 unit tests. I love being able to run them and know that the refactoring that I had just done didn't break any code that someone else was relying on.

Wednesday, February 06, 2008

CSS... what a pain.

When I first learned about CSS, the only reason given to me for it was formatting. I didn't get it. Tables already did that. But CSS is so much more. Tables keep everything in place with relation to each other, but CSS can be floating, and layered, and so much more.

However, now that I'm starting to dig into CSS and actually try setting up a page using it, it's a real pain. Things appear different in IE than they do in Firefox, and different again in Safari. Steve Jobs has done a good enough job of bringing MAC into the fold that Safari cannot be ignored.

It's odd how sometimes the open source solutions are a bigger pain than the proprietary ones. A standards community says how the CSS should act, but each company or group implements it differently, and the people who use it are stuck having to put in hacks to get around the companies differences, or else they just design for one browser and add a note to the screen stating it works better in a different browser.

I don't want to determine for a user which browser they should use. I don't want a page that I design to only work in one browser, but I also hate hacks. I don't want them to make the code look ugly. It's too bad the people making the browsers can't just get along enough to follow the standards.