Happy New Year

As I type this there are parts of the globe already five and a half hours into the year 2009. It's just 9:26am here in the bible belt of the United States of America and I'm at work (blogging in my break of course).

I'm thinking about organizations and how they view success. Each organization is it's own ecosystem, and they all have their own forms of Darwinism. The key to survival of the fittest though is first to define what particular definition of fittest that particular system accepts. In some ecosystems in the business business world the fittest might be the achiever, while in many the case you see is that the achievers are the ones considered the weak, the ones that have to go. When the herd is moving toward a stable sense of mediocrity then the ones who get ahead will be the ones to find themselves victims of the hazards of that environment (typically some form of bureaucratic, executive management tyranny), and as in most any ecosystem, the individual weak or dumb enough to be outside the strength of the herd is the one that gets eaten by the puma.

Analogies aside, I wonder what it really takes to come into an organization and introduce true improvements and get the organization to see that those improvements are GOOD. Let's face it, it's not that you can convince people that what they're doing is WRONG, they've been doing it and it works (for lack of any other results that is). So the goal in my new year is to work on demonstrating the value of improvements, and make it show real value. Instead of trying to convince people that what they have is wrong, show them what life would be like with what they could have.

So if that can be summed up in a concrete resolution: As a software developer and business person I will find better ways to demonstrate value added practices, whether in code or business process, in order the introduce improvements into my work place.

It's right up there with my other resolutions:

• eat better (suggested by my loving wife who, for some reason, wants me to live a long life)
• use linux more
• write some software non-work related (open or closed, just write it)
  

until next time, HAPPEH NEW YER!1!!1!
Les

The necessity of a daily stand-up.

Latest post on Approaching Agile.

A daily stand-up would definitely make it easier to absorb and assimilate new developers to the team.

until next time
Les

My new blog project.

In my new job I will be Approaching Agile. There is much work to be done, I'll try to fight the good fight and keep you all informed as I go.

Follow me if you're interested.

Until next time,
Les

TDD at M$??? Oh my!!!

Phil Haack is one of the few Microsoft/.NET bloggers that I follow. He just reached a milestone of 1 year with the software giant working on many ASP.NET initiatives. What I think is great about this guy is his love for open source (yes, from a microsofty), and his passion for Test Driven Development. Here's a quote from his latest post:

I’ve also been involved in division wide efforts to help other teams understand Test Driven Development so that our products moving forward will take TDD into consideration in the design of their products.

It just gives me a warm fuzzy feeling to know that there are actually people inside Micro$oft who actually care about best practices like TDD.

Way to go Phil and congrats on 1 year with the evil empire Microsoft.

until next time
Les

Skreeming with foxytunes

I was recently introduced to Skreemr (http://skreemr.com). An mp3 search engine that serves up mp3 from blogs. It's a neat way to sample music and check out stuff as you hear about it (among other nefarious things since you can download the songs as well.

I heard there was a player that would allow you to play a list of songs you retrieve in your search but I didn't want to download any new player. Then as I was checking out some Gorillaz tunes I saw that I had a little widget in my browser, when I started messing around with it I realized it was a part of one of my favorite Firefox plugins: foxytunes. It allows you to play all the songs in a web page as a single playlist. heres a screen shot:


until next time
Les

TDD: Prove what you know

Accepting the concept of TDD (and yes I mean test FIRST development) was a tough task for me. At first I didn't understand the complete benefit, honestly I can't admit that I do completely now. But I've come around none the less.

When working on a project it is pretty much impossible to deliver code without having a bit of an understanding of what it is the end result of that code execution should be. The user doesn't care about implementation. All the end user knows is that when they submit this data in that field then something specific had better happen as a result. I didn't really grasp how that was a reflection of what test first meant.

Now I like to think of the end user and my unit test as the same thing. Both are simply executors of my code. I can't know what the system is supposed to do unless the end user tells me so. At first that was all I saw. The user says so and then I code the implementation, then add some tests. Now I see that if the user tells me what the requirement should result in I replicate that in a test, and that proves without a doubt that I understand the requirement. If you don't understand it enough to write a test for it then you sure as heck don't know enough to write code to implement the requirement.

Not only does this help you better grasp the requirement before diving head first into coding, it also gives you an upfront contract that is based on vernacular communication. That adds a quality check. If you write the test first based on what you understand the requirement to demand then you write the code to satisfy that test and hopefully you don't write any code outside that (unless necessary, remember to use your head but remember to prove any code changes with tests for quality assurance).

So as long as it's sane I'd like to set a rule for myself for future coding:

If I don't understand enough of what is required in order to write a test
then I don't understand enough to code period.

Keep me accountable.
Until next time
Les

Just Another Glance at Pair Programming

I've always had issues with pair programming. It's not that I disagree with the value claims that people associate with it. I just have personal issues with it. Here are some of the things that have bothered me:

• Watching someone else use a computer is like fingernails on a chalk board. I know I'm not perfect but seeing how other people get things done with the mouse and keyboard gets my egometer running and I just want to push them out of the way screaming "IF YOU CAN'T DO IT RIGHT DON'T DO IT AT ALL", but honestly... it's not about the right way to do things, it's about the way I do things.
• Staying focused while navigating is an uphill battle. I'm used to working alone. I'm also used to thinking with my fingers attached to the keyboard. I've always had a hard time being the navigator for too long. I just have a tendency to get bored.
• Having someone else tell me how to spell my variables names is punishable by death. I don't care if you think the variable should be fooBo when I type fooBO, next time you drive you can change it yourself.
• Some of the old reasoning behind pairing is obsolete with the use of powerful IDEs like Eclipse, Intelli-J, and others. I don't need someone telling me I missed a semi-colon at the end of a line because eclipse does that for me.

Honestly I have to admit that some of those things are petty and just personal quirks. At the end of the day I have to think about my motivations and just maybe those things shouldn't be that big of a deal (as long as I didn't strangle someone). Other things may require a little understanding of what's really going on when two people truly, productively pair.

What is the point? I'm not going to dig into any text books or even reference wikipedia on this. This is just me stating things from the perspective of a lowly developer.

Pair programming helps keep individuals on track. When I work alone it's too easy to take that personal phone call or do some web surfing (yeah, even tracking down technical, java related web info has to be considered personal surfing). Pair programming increases the quality of code. It's not about missing semicolons or mispelled variables anymore (thanks Eclipse), it's all about checking in code that is clean and efficient and easy to maintain. When you have more than one person working on code it's much harder to make stupid mistakes. Yeah, I said stupid. And we all make those mistakes from time to time. Copy/paste mistakes. Unneccesary else mistakes. So many things that are too easy to do and really easy to overlook will more than likely be caught by a pair of programmers than a Han Solo cowboy coder.

What about staying engaged and focused? I do have a problem with that some. But I recently did some pairing in a way I hadn't thought of before. Once we understood the task at hand my pair wrote the first unit test (yes, we wrote the test first), then when it ran and failed he slid me the keyboard and told me to implement the code to fix the test. I did, then I wrote the next unit test which failed and he got to implement the solution... that was the fastest day of work I think I've ever had. I was very impressed. Personal conversations were cut to a minimum and we both stayed focused on the task at hand since we were both implementing the code in tandem.

I'm not saying that everyone should pair all the time, but I don't think it's a bad idea to do it a little more than you may be doing it already. Every programmer's goal should come down to delivering clean, quality, bug free code. I think pairing will definitely help you in achieving that goal.

Until next time
Les

Welcome to the Jungle (of extreme programming)

This past week I changed teams at work. I went from a standard, cube oriented team to an xp (extreme programming), team room situated team. After 5 days I have to admit I'm very impressed. Things seem to just flow, and that includes the time in the day.

In my previous team we used a bastardized scrum process. What I mean by that is we worked from a log of broadly described requirements and we had a daily stand-up meeting (scrum meeting) where each person reported on their current workload. But between those daily scrums it was mostly cave time in each person's cube where they worked on whatever they pleased (which means a lot of personal, non-work related stuff). Except for 1 solid leader on the team and 1 or 2 others this was pretty common (guilty).

On the xp team it's more rigorous as far as daily tasks go. It's a mix of xp, scrum, and lean methods. Everything, and I mean everything, is done in a defined process. From the way the requirements (user stories) are defined and accepted (yes, accepted by developers), to the way tasks are maintained on a kanban board and everything is required to be done by a pair of programmers doing test first development. And even when a pair gets the task "done" it isn't officially done until it gets "accepted" by another pair (a process that when done properly guarantees almost zero bugs released post-development).

I know it sounds a bit legislative, and honestly I had my doubts as to how it would affect me. But the work load is easily divided and things get done. In a 5 day iteration we clear the board and if we need we can pull stories that are ready in the backlog. The only problem this team has had is lack of ready to go stories in the backlog (but that is changing with the addition of 2 in house Business Analysts).

So far I'm loving my new work environment, I really don't miss my cube (but yes Brian, I do miss you man, you should offer to take someone elses place :-) ). I want to get into details in later posts about the kanban board and some of the ways I've paired and also our use of Fitnesse which so far is mind blowing. I'm marking down week 1 as a productive week.

Until next time
Les

Lone Star Software Symposium - Day 3 Recap

Meanwhile, back at the Ranch...
So the conference has come to an end and several hours driving and a short night's sleep in my own bed and now I'm back at work. This was a great experience for me. I would definitely go back to a NFJS conference if I got the chance.
The final day was no let down. The four sessions I attended were great.
The recap:

Design Patterns in Java and Groovy

I know I've gone on and on about Groovy, but this class really got my attention. This was my first session with Venkat Subramanium. Venkat is the author of several books (one of which I already have) and a very charismatic speaker. What he did in this session was present several common design patterns in Java, discuss the complexity, and then write the same functionality in Groovy right there. This was an excellent session to see some Groovy in action and see just how simple and easy it makes very robust Java tasks.

Caring about your Code Quality

This was more of a speach presentation than a coding presentation. But with Venkat back at the helm that's not bad at all. This session covered why Code Quality is important and why caring about your own code quality is important. He shed light on a lot of common coding fallacies and practices. This is a very important subject that encompasses every facet of Software Engineering, not just the Java world. Great stuff.

Agile Test Driven Development With Groovy

This and my last session were both presented by Jeff Brown. This was an interesting class to me. It started differently than I expected with a background of unit testing and TDD. But once Jeff got into the coding section and really greased the testing wheels with some Groovy goodness it was really interesting. The simplicity of your code that Groovy provides really makes some remedial testing tasks almost too easy (compared to what it takes to do those tasks in Java).

Powerful Metaprogramming Techniques With Groovy

This session really got into the mud with the meta-programming capabilities provided in Groovy. His examples were pretty cool. He made several builders (xmlBuilder, outlineBuilder) and showed how simple it is to manipulate compiled classes on the fly to empower your code to really do what you want it to do, not just what your framework wants it to do. He explained a bit about the ExpandoMetaClass which is a very powerful tool in Groovy (and a tool that came from the Grails project). Again, good stuff.

Conclusion
This conference was very useful to me and my colleagues and I have decided that Groovy is going to be a tool we use in our framework. We'll start small using it as a helper for our unit testing, then we'll see where we can take it from there.


Until next time
Les

Lone Star Software Symposium - Day 2 Recap

Here I am at the end of Day 2 and I'm miserable. There are several reasons for that, but they don't have anything to do with the Conference itself. One reason is that I miss my wife and my son. Another, and probably the biggest, reason is that I'm stuffed beyone enjoyment on BBQ from Red Hot and Blue because I have mostly no self control when it comes to BBQ.
Here's the wrap up:

Filthy Rich Clients with the Google Web Toolkit, Part I

Overall this is a very interesting toolkit. It allows you to development heavy, ajaxian, rich, javascript based web apps by writing nothing but Java code. Google has written a compiler that takes the Java code and compiles it into multiplatform, crossbrowser Javascript. It's really slick and I could definitely see using it to throw together some personal projects. The session wasn't horrible.

Real World JSON

This was another course by Scott Davis and I really enjoyed it. JSON (Javascript Object Notation) is basically the best alternative to XML (the 'x' in AJAX). JSON let's you express objects and lists of objects as plain text (and what's more light weight than that?) and process it right in your web page without have the heavy, cumbersome syntax of XML to grind through. I could see using JSON in future web endeavers. Good presentation.

Grails - Agile Web 2.0 The Easy Way

This got me back on track with my new trend in self study. It was presented by Jeff Brown and he did a really good job at showing the quick and dirty of what Grails really is. This was really a repeat for me since I attended Davis's Grails session yesterday, but he added fresh light to areas for me so it wasn't a waste. Good presentation and a good primer for the next session.

Advanced Web Development With Grails

So this was the best session of the day. It was Jeff Brown's second session and it really dug deeper into the workings of Grails and building real world web apps with it. He showed us the power and EASE of creating custom tags in Grails (as opposed to the painstaking process it in the JSP world). He demonstrated some remote calling and object relationships (managed right in your bean object and persisted on the fly to the Database, yeah, that's right). I definitely think that the entire Groovy/Grails paradigm could change my programming landscape for good, if only I could get it accepted at my job.

As I said to begin, overall I'm enjoying and learning. I would recommend this conference to any, ANY Java based developer.

Until next time
Les

Lone Star Software Symposium - Day 1 Recap

Without going into detail regarding the trip to Dallas and the typical checking into the hotel I'll just say that for the most part today is what you might expect from the first day of a conference. I really enjoyed the sessions I attended today. All three of the sessions I chose were led by Scott Davis and all things revolved around Groovy.

The Blue Pill

The first session was Groovy, the Blue Pill, and yes that is a reference to The Matrix and the next session carried the reference further. The Blue Pill was basically a crash course in Groovy. What it is. How can it be used. What are some basic features that make it so groovy and not just Java without the semicolons (which is optional). It was a good track for me as I'm still fairly new to Groovy. Sure I didn't really get a lot of "new" out of this one since I've been reading a lot of intro to Groovy stuff lately, but it was refreshing.

The Red Pill

The Red Pill was just a continuation of the Blue pill. After the intro course he was now able to present more nitty gritty Groovy functionality. It covered closures, metaprogramming, and much more. A very good session for me as this is where I'm standing on the Groovy landscape.

Grails for the Struts Developer

This was a very interesting session to me. He began and spent a large part of the course talking about Struts. It's origins and it's benefits. Much praise was discussed for what Struts had implemented in it's day. But then came the current state of development on the Java platform and some negative topics regarding Struts were breached. Then he introduced Grails and talked about how you can simply use Groovy over your current Struts apps. Then he rolled up his sleaves and created a Grails app from scratch. With scaffolding doing all the work it was a matter of minutes before he had 3 CRUD apps up an running. Not a lot of new stuff for me, but a good refresher preparing me for my session on Grails tomorrow.

Keynote

Interestingly enough to me, the keynote speach at the end of the day was almost the best part (not taking anything away from Scott and his Groovy kool-aid). It was an awesome presentation about the state of software development and how long it's been this way and where it will likely end up going (which looks bad from here). He talked a lot about development anti-patterns that are common and I swear the man must be camped out or video taping our department because the first six patterns he discussed were common every week practices for us. I wasn't really shocked, but hearing it all explained so pointedly really made me wonder how much longer I can put up with it (as if I wouldn't run into the same issues elsewhere).

Conclusion

Overall the first day was very enjoyable and full of information. I'm looking forward to tomorrow's sessions.

Until next time
Les

Numbers the Groovy way

So far I'm still at the beginning of my journey into the wonderful world of scripting with the Java based Groovy. I'm seeing a lot of neat things, but still I'm just scratching the surface. One thing that I see so far that is really useful is the way numbers are handled.

In Groovy, everything is an object. There are NO native primitive types such as Java (which is Object Oriented with a handful of primitive exceptions to the rule). So in early iterations of Java you had to manually box your primitives into objects to work with them in Collections and other Object based processes.

Groovy has that covered. In Groovy you can reference a number just like an object (because it is an object). Then if you need to make a List of int's it's boxed on the fly because there is no int but everything that would be a Java int is and Integer (auto-boxing to the extreme).

// using the Groovy built-in function .times you can
// simply say you want to do something a number of times
// without having to setup a full fledged for loop
10.times
{
 println "my line"
}

That's just one sample, but I hope it show's you how simple it is to work with numbers in this groovy scripting language.

Until next time
Les

Lone Star Software Symposium - NFJS

This weekend is the No Fluff Just Stuff (NFJS) conference in Dallas and I actually get to go. I'm pumped about this since last year I missed out when it was in my back yard (almost literally) and this years OKC area conference got canceled. I will be posting nightly (no promises) about what is covered but I wanted to go ahead and give a heads up on what I plan on attending for those who care and those who don't.


Day 1:

• Groovy, the Blue Pill: Writing Next Generation Java Code in Groovy -Scott Davis
• Groovy, The Red Pill: Metaprogramming, the Groovy Way to Blow a Buttoned-Down Java Developer's Mind - Scott Davis
• Grails for Struts Developers: A Groovy Alternative - Scott Davis

Day 2:

• Filthy Rich Clients with the Google Web Toolkit, Part I - David Geary
• Filthy Rich Clients with the Google Web Toolkit, Part II - David Geary
• Grails - Agile Web 2.0 The Easy Way - Jeff Brown
• Advanced Web Development With Grails - Jeff Brown

Day 3:

• Design Patterns in Java and Groovy - Venkat Subramaniam
• Caring about your Code Quality - Venkat Subramaniam
• Agile Test Driven Development With Groovy - Jeff Brown
• Powerful Metaprogramming Techniques With Groovy - Jeff Brown

I'm really looking forward to it.
Until next time,
Les

Feeding with no RSS

So I recently came across an online tool while reading my feeds called Page2RSS. From their site:

It is a service that helps you monitor web sites that do not publish feeds.
It will check any web page for updates and deliver them to your favorite RSS aggregator.

I did see a warning that mentioned not using a page that get's updates by the minute since this site will crawl the page every 10 minutes and that will really get your reader down.

Having the tool tucked in the back of my mind I didn't really have a site to use it on at that moment, but I figured it would come in useful eventually. I was right. My church maintains a web page with sermons (mp3 links) posted (no Bubba, I'm not getting preachy, I really am just talking about the tool). They update it about every week, sometimes every 2 weeks. I like to keep an eye on the sermons they post since we miss a lot and don't go to evening services. Instead of having to check the page I used the handy Page2RSS tool and now I get updated when the page does.

It just crawls the page and checks it versus previous versions so I wondered how it would look. Here is a sample I got tonite (here is the sermon page)


As you can see it adds new entries from the page into the feed from top to bottom just as they added it to the page. And since the changes in question have links to mp3 files it adds those links as well without posting the URL as text and dirtying up my page.

Pretty cool by me.
Until next time,
Les

What's so Groovy about Grails

If you haven't heard of Grails or Groovy maybe you have heard of Ruby and Rails. Basically Groovy is a Java based Ruby (grossly oversimplified definition), and Grails is just Rails for Groovy.

What's it all about? I'm in the process of figuring that out at the moment (in between work and family and my recurring tours of duty in Modern Warfare). I'm reading Groovy in Action and going over some online tutorials for developing web apps with Grails and it's very impressive (this coming from a guy with no prior experience with Ruby on Rails).

Grails is a web framework that is grounded on Convention over Configuration. In other words, we all know what a web application should do, and most web apps are built in a similar fashion, so why not just say "this is the way it should be setup" and then set it up that way. So in Grails I can type one command and BOOM a web app is generated right in front of me without any configuration from me, all I have to do is add the information that makes it my application (mostly domain stuff). Unlike struts I don't have to spend mindless time configuring and reconfiguring XML files just to get a single web page to display. I get to do what programmers love best: program.

I don't know a lot about Groovy yet, but I'm working on it. Will I be able to use this in my work? Maybe not. But I might find ways to use it in my daily work on my own workspace. We'll see.

Until next time
Les

Paine Management Redux

Lead, follow, or get out of the way. - Thomas Paine

As a follow-up to my previous post I'd like to pose a better team building thought. Instead of management asking:

"How do you handle being on a team with members who aren't as
up to speed or as skilled as you are?"

I say a team should be driven with this question, and it should be addressed and accepted and enforced with ALL team members:

"If you are found to be the least skilled on the team or you are not
as up to speed as the rest of the team what will you do about it?"

The team will constantly look within itself and address the weaknesses and if individuals are open to being honest and responsible for their skills then the team as a whole can better take care of each other. I understand though that this is a perfect world situation.

Until next time
Les

Paine Management

Most people who know me are aware that I am harsh in only a few situations. Most of the time I'm a fun loving, gullible, happy-go-lucky kinda guy. One of the things that really gets my skeptic radar turned on is lower to mid-level management and the use thereof. Maybe this is because I worked for myself a couple of years after college. Maybe it's just the fact that I've always been a little rebellious against authority figures.

My view of the role of management especially in IT is an oversimplified cliché:

Lead, follow, or get out of the way. Thomas Paine

That makes 3 possible categories to delve into, but really I only want to discuss two distinct middle-management types. While in a morning enrichment session this morning with some of my closest colleagues I made a allusion to two particular management style from the abyss that is my imagination. There are givers and there are takers (leeches).

Givers
Few people in IT get to work for givers. The giver is a contributor. Maybe they don't write code, some do and hopefully they're good at it. Givers are ready for change at any moment in the project life cycle and make sure that their influence on the project does everything it can to move the project toward progress. The giver only asks questions when absolutely necessary. The giver will lead when required, but knows when to get out of the way of the people actually doing the work. True givers may only exist in a vacuum of the IT space.

Leeches
Most IT workers have come into contact with some sort of middle-management leech. They do what a leach does best: take. It's usually hard to spot a leech when you start somewhere. At first they seem very helpful and very productive. They spend their time being in the act of being busy. Soon though it's easy to notice that they're helpfulness is a little too helpful. Helpful to the point of no helping. Leeches use classic phrases like:

Far be it from me to get in the way of progress, BUT.

or:

You guys know what you're doing, BUT.

or:

I'm just like you guys, BUT.

Are you seeing a pattern? Leeches come in with the appearance of wanting to contribute. Wanting to help. BUT they always have some aside that they have to share because the powers that be (someone that we never get to meet) has decreed that there will be beatings if you cross this imaginary line. The leech will not get out of the way on any issue. They want to be right in the middle of it so they can either take credit for a job well done or hand out the "I-told-you-so"s once something goes wrong. And it's the possibility of failure that drives the leech to constantly add friction to progress.

At one interview I had I was given a few minutes for a pseudo-interview with lower-mid-managers (basically they were designated the same as Project Leaders). It was less of an interview than than it was a get to know me session. I did most of the talking. One thing that I was asked was:

"How do you handle being on a team with members whose skills aren't as advanced and who aren't as up to speed on the platform/language/project as the rest of the team?"

I took the question at face value and answered it with elegant clichés and tried to show how much of a people-person and team player I am. After working there for a while I realized the importance of that question. It was a proof of what I experienced at this job. They wanted to know what my view was because their view was that they weren't going to do anything about those people. They expected no improvement from those employees. They were afraid they would rock the boat and their happy little family of developers would turn on them. They managed with tied hands whether self-imposed or not.

To me this is classic leech management. When it comes to managing people they're impotent, but if something comes up dealing with a change of tool or a new implementation or process where they can enter their contributions/ideas/endless list of questions, they will. And somehow their contributions seem to suck the motivation right out of the group. Most of a leeches contributions will actually improve the quality of work-life for people who don't help the project progress. That's been my experience anyway.

What's the best way to deal with leech management? It should be as simple as dealing with real life leeches. Just pull them off and discard them. But I can't say that I have a solution that is viable. I guess that will be for another post probably years from now when I've had enough experience to make suggestions on that sort of thing.

Until next time
Les

The bottle thing

If you follow my tweets then you got this from yesterday. Well here is a pic:


He has really been able to hold his bottle for quite some time, but I guess he didn't feel like it. But lately he is really taking care of it without much coaxing.

It's a sad and happy day. Sad because that's one more thing that is now just going to be a memory. Happy because I can finally just give him a bottle and not have to hold it until he's finished.


Oh and by the way, the chicks really dug the hat. :-)

Until next time,
Les

Why the DMV won't improve

Annette had to get her driver's license renewed today. She has a Commercial Driver's License (CDL) so she can drive a school bus if needed. Well, since it's a CDL she can't just go to the Tag Agency and renew; she has to go to the Department of Motor Vehicles (DMV) and get everything processed there THEN she gets to go to the tag agency to get the new license.

So at the end of our day she is telling me of all that went on. She was there for 2.5 hours just waiting to get to see someone. Being a teacher she is always looking for ways to make things more efficient. I guess having to deal with snot nosed prepubescents really makes you think of ways to improve processes that speed up any kind of standing in line.

Well, she starts explaining to me how they could have had multiple receiving lines for more specific purposes instead of just one general purpose line (i.e. she wants a line for inquiries and a line for tests and a line for renewals etc.). And I remember that the Social Security office is exactly the same way. Long, general purpose line and a wait that takes way too long.

Why is this? They've been running things the same way for long enough it would make since that they come up with more efficient ways of managing their daily lines of people. And then I remember. These places don't have to improve their process. They don't have to worry about "customer service" because they don't serve customers. They handle a captive audience. People don't have a choice about standing in line. It's required by law to be there and do what you are doing (for the most part) so you can't just decide against it if they're not nice to you.

The rest of us don't have this power. We aren't working government jobs with mandated requirements. We deal with customers of some type. And if we don't please those customers then they go somewhere else. Those government bastards are lucky.

Until next time,
Les

Over stating the obvious

Playing

So I've reached Level 55 (Commander) in Call of Duty 4 and I'm not currently planning on going Prestige mode. Besides, it's not even available yet since I have to earn it as if it were Level 56. Prestige is a mode (or rather 10 modes) of reseting all that you've earned in the multi-player mode and starting over like new. The only thing you're left with to claim your badassness is a special medal next to your gamertag in-game. 10 prestige modes means 10 medals, but you have to go level 55 each time.... I don't think so.

The game is still fun. I haven't been let down since getting to take part in the Beta back last September (07). The single player is a solid play, action packed and a decent story and an ending that I thought was better than BioShock's (sorry Nathan). But really the most awe inspiring moment of the single player game was about half way through. If you played it you know what I'm talking about.

But the real crack addition that this game offers is the multi-player. It's fast paced and hardcore. There are 16 maps and enough game types to keep this casual gamer pleased for hours without pause. Sure I'm ready for the DLC coming next month, but that will also be competing with one of my FPS first loves:

Rainbow Six: Vegas 2. I've been a fan of Rainbow Six since I played the original on my PS1, although I didn't play any after that until Vegas on my 360. 2 comes out on the March 11th and I've decided to rid myself of Assassin's Creed for it. After all I did get all the gamer score out of that one and there really is no replay value in it for me. I thought there might be, but that would really just be a waste of time.

Until next time
Les

You're perfect! Don't change a thing

In our group's architecture meeting recently we (developers) were given a warning about code changes effecting (or is it affecting?) production. To sum it up we were told: "do not make changes unless they were absolutely necessary or be aware of consequences". And I'm wondering are there really any of us sitting at our workstations trying to think up changes to the system that aren't necssary? That aside though I'd like to examine the paradigm that this kind of warning is really introducing.

One thing to always remember as a software developer is that anytime you make a change to any system you are taking a chance of adversely effecting said system. Yes, there is a chance you could break something since no one and no system is infallible. So what do we do about this? Avoid doing our jobs? I guess before we can address that we have to define what it is we do as software developers.

Developers have a simple job. Write code to deliver software that performs requested functionality. No matter where you are or what you are developing this applies. It's simple I know. Too simple. But there are so many strings attached to that job description that you really can't sum them all up in a job posting of any sort. You have to consider that the code being written on day 5 is not going to 100% valid and in scope on day 35. Imagine the difference between requirements on day 5 and day 605. Software is a process. It has to grow which means it has to change. Scope changes. System requirements change. User requests change. The older a system gets the worse the code smells; no exceptions. So while a developer is in charge of delivering functionality they also have to consider these things: scope change; code maintainability; scalability; stress handling; and even the probability of the application surviving a complete system failure (or being usable after a zombie attack).

That being said, a developer knows that systems are going to require change. There are going to be changes that are directly related to user request and then there will be those changes required due to the need to *gasp* refactor (thank you Martin Fowler).

Sometimes its as simple as updating or migrating to a new tool in our application. A couple years ago we switched from using EJB2 to using a Spring container for our framework, it wasn't a user request, but we needed to change from using EJB2. That needed to be done for many reasons which I won't go into here. It required a lot of sweeping code changes. There were a lot of hiccups along the way some of which we're still running into. But it didn't end the world as our application knows it.

There are other changes though. Changes that aren't directly linked to upgrading or migrating tools. For instance, your application has been in development for 4+ years and is still growing. There are parts of the framework that are duplicated due to original configuration and short sighted development choices. Or even just the fact that code pool x is just to freaking big to manage and needs to be broken into smaller more manageable components. These changes won't offer any direct value to the end user (on the surface anyway), but they contribute to a cleaner more efficient code base. And a cleaner more efficient code base helps keep an application running smoothly, contributes to easier maintenance of the application, and also helps keep good developers sane (which is a good thing, insane developers do insane things like blame their tools for all their problems).

So, do we avoid these changes for the sake of what is stable now? If we do that it only helps those stable apps for now. What happens when that currently stable application in production needs a new feature or has a bug that needs fixed. Now you have to work in the mess that should have been cleaned up months or even years ago. Now making what should be a simple change is like trying to add a new floor to a four story building, but you have to add the floor in the middle of the building, not the top.That means that the chance of introducing more bugs into the system is multiplied (the risk is already there just because you're making changes in the first place). The change will probably take longer than it should. And on and on we could go with this.

Developers write code. Developers make changes to make the system better (for performance and maintenance). It is risky. That's a risk we're willing to take.

Until next time,
Les

Dev vs. Dev

Playing around with Google Presentation. Enjoy!

RSS Reader of Choice

I recently switched from using Bloglines(new beta version) to Google Reader for my RSS needs. I like Bloglines, but I thought it was time to hand Google another piece of my online lifestyle.

I like how Reader integrates easily with my GMail account and some of the added features (like my "Shared" items). What I wish Google had that Bloglines offers is anonymous email accounts.
With Bloglines I could generate a random email address (@bloglines.com) that would be added as a subscribtion in my feeds and I could use that address to sign up for services that require an email (if I didn't want to give them my real email). Also, I used that to subscribe to some user groups email newsletters, so I got to read them like feeds instead of having to mess with them in my inbox. Maybe Google will add this eventually, but for now I'll keep using Reader.

Until next time
Les

Just like any other geek I have always aspired to someday write a book. I guess the key there is "someday". So as long as I'm still alive I can dream that dream. I've often wondered what I should do to begin. I actually have started a couple of time on different projects. As I typically do though I start strong but then fizzle out. I guess it can't just be some off the cuff random thought, I have to find something that actually means something to me to make it work. As the saying goes I have to find my muse.

So where do I look for inspiration. When taking on a project such as this there are all the usual suspect resource pools to dip in for inspiration: personal history/beliefs, current events, or just mere imagination. I've tried the imagination thing. Wrote about one and a half chapters and hit writers' block. The pool of my imagination is pretty shallow it seems. So I've been thinking how about mixing it up a little bit. I could write based on my geographical background and use what other people imagine about that particular region. This could be interesting if done correctly since I come from an area that most people seem to associate with the movie Deliverance, which actually took place in Georgia, but Southeastern Oklahoma tends to have a reputation for being equal to the local of that story.

If I could find the right literary hook, add some plot to it, twist, and actually find the right audience I might be able to get it going. But let's face it; it's hard to produce a truly original idea since almost everything has already been done to the nth degree. So for me it's really a fear of having any potential audience just shrugging it off as if it's a rip off of something they're already familiar with.

Regarding the medium of delivery, I've actually considered starting a new fiction blog and write chapters at a time. Register it with creative commons and try some brute for self promotion on wikis and forums. This might be a better way to start for me but only if I could get a following that would put me in check when I stop posting chapters. But would I be able to sell a product that has been readily available for free on the information waves of the world wide web? I guess I could get a following (assuming I self promoted good enough to generate some buzz), I could then cut off the blog with a final post stating "To be continued in a bookstore near you!" But that would be a dangerous move especially for someone who from societies perspective is a no one. Don't piss off the audience, not until you've got a big enough name and pay roll to get away with it.

This needs more thought and obviously I would have to develop a working story line before any of this is even viable. So...

Until next time
Les

Guy stuff

One of my favorite all time guy movies is Desperado, the Robby Rodriguez flick with Antonio Banderas.
I started listening to the soundtrack today for the first time in probably more than a year and it reminded me I need to watch it again just to reaffirm my manliness (as if I needed to do that). Well, I can't. I own it you see, but I own it in the out dated format of VHS. For you kids that read my blog that's what we used to watch before teh DVD became the thing and the internet was way too slow to download video (I know this is arguable). Anyway. I don't have a VCR hooked up in my house (that's the machine that plays the VHS). So, for my manliness' sake, I need to go pick up this movie on DVD.

Until next time,
Les