Change: The Ever Present Constant

Yes it's been more than a while since my last post here. I'm sorry but I won't be like all those other bloggers and start this post with an apology.

I just rounded off the end of a year doing government contracting. Eight months of which I can't say much (too soon), the last 3 months of that though were very interesting however to my geek side. I got to brush up on my .Net skills and check out the latest in C# technologies (impressive) and I also got to dabble a bit in Java Swing with a HUGE GIS application.

But that has come to an end and I've started a new chapter in my career working back in the private sector doing Java web development. I have to say hello again to Java 1.4, Websphere, Rational Application Developer, AND EJB 2.x

So I've got to get back in the groove of these things and while I'm at it see how I can contribute to maintaining and improving these web applications into a growing industry. I may be jotting some notes here (don't count on it) while I do some digging into the in's N out's of these things again.

All in all things are good.

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

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

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

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!

Measuring Developers

I need to get back on track and talk about programming. There is a lot that has been on my mind lately but I've been to lazy to put it together. I've been thinking about developers and what makes one good and another one bad. In the end developers are people, and the nature of people is very obscure and random so no two people can really be measured with the same rules. Everyone has different strengths. Not everyone is going to be a quick study and natural tool-smith. So it isn't fair to say "so and so can pick up anything quickly, so they are worth more to my team than oh slow Joe over there".

I guess it comes down to responsibility. Sure you may not be the strongest Java programmer on the team, but how are you being responsible for what you do work on? How are you committing yourself to the tasks at hand? Can your team count on you or are you a quitter/winer?

There is way more on this and I don't have time right now.

Until next time
Les

That's not how it's done

Growing up as an aspiring guitarist I used to take my acoustic to school and play on the lawn during lunches. It was fun. I always enjoyed playing. Trying to tackle new riffs or old ones, it kept me busy. Sometimes the funnest thing to do was take a song I'd been hearing a lot of and make my guitar play the same notes. Of course there were always tabs which were a very easy way to learn any song. But sometimes it was more interesting to work it out just by ear.

One song I learned by ear was a popular one from the Goo Goo Dolls. When I was playing it at school one day a friend stopped me mid-intro and said.... "That's not how it's done." I stared for a second and asked what he meant. He informed me that he had the sheet music from that album and the way I was playing wasn't the way that was written in the book. I asked the rest of the group what song I had just been playing and they all agreed it was the song in question that was coming from my guitar, but my friend wasn't interested in what it "sounded like", he was learning to play based on the exact way the artists themselves played. Forget music theory or the fact that there are multiple variations of the same notes/chords across the fretboard of a guitar (same as any other instrument). He wasn't really interested in understanding music or the instrument, he was only interested in understanding the way the artist played it.

Exit the world of rock guitars and enter the world I'm currently in: software programming.

Many coders don't have a grasp on what it is that a programmer does. The funny thing about that is that in many businesses the 2 types are paid pretty much the same compensation. For the coder it's only relevant to know that a piece of code is written in comparison to any other code they can find to copy from. Their only true requirement is that it meets user requirements. A programmer is more of an engineer. It's not good enough to just borrow code that meets requirements. The programmer has to know more. Why does the code do what it does? How does it work? Can it be made better?

Oh yes, the coder will take pride in the claim that they know the business requirements but they can't explain why they can't deliver successful products in a timely manner with quality rock solid code. By knowing the business requirements the coder can easily find other code that meets those requirements and voila they've written a program by use of a few right clicks of their mouse.

What does it take to separate yourself from these copy/pasters? For one, have a growing knowledge of your tools. By tools I mean the platform you're developing for, the language you're using (including libraries and the way the language works with the machine), and even the IDE you'll be using (i.e. Eclipse). If you're going to work in this industry you have to be a nerd and that's not as bad as it seemed when you were in high school. Now that we're in the real world a really good nerd can bring home a way better bottom line than the most popular jock in your high school (who's most likely working in a local factory pulling in just over min. wage or working at his uncle's auto dealership). So don't worry, be a little nerdy. Spend some time reading technical books and articles that help you immerse yourself in your craft (although don't forget to take the time to do other things you enjoy, like spending time with family and friends, because nerds do have friends here in the real world).

end of rant
Until next time
Les

New systems of management

I found this little post pretty humorous yet frighteningly accurate:

@$$hole driven development

Whatcha think?

Until next time
Les

Rant #{random}

I know I have deadlines and so much to do, but I have to rant about this. My therapist says it's good therapy, or at least if I had a therapist that's what I would pay them to say.



So we've been given a very strict end of year deadline on our project, you know, the whole 5 gallons in a 2 gallon bucket bit. Anyway, this morning I'm checking my email and from one of our managing Business Analysts I received a note regarding something that just blows my mind. This person is wondering why in some functions in our web app the text box for the login ID is bigger than in other functions...



Yes you heard me correctly. They are pushing a goal that is unreachable and they want to penny whip us with stupid discussions about textbox size. UNBELIEVABLE!



until next time

Les

Currently Reading: Practices of an Agile Developer

Recently picked up this book.







Info



So far it isn't a bad read. I figure if I'm going to chat about things such as agile in this forum then I should at least educate myself a bit.



Maybe I'll do the whole book report thing on it.



Until next time

Les

Feeding the Machine Part 3: buzz words and tech speak revisited

Sometimes my grumblings lead those around me to believe I may not be a person who is very agile-friendly. I know I come down hard on terminology at times, and for good reason: terms don't a finished product make. Now, I know that I've talked on some of these subjects before, but as long as blogging is cool the topic should be ripe.



My biggest concern with the whimsical world of agile practices is that in my time (which is a limited base of experience I know) I've seen more preachers than practitioners. This is probably just due to my lack of experience and such, but it still keeps me skeptical.



Take the example of a small town church having what is referred to as a "Revival" (common term to those raised in small town churches). Usually you bring in some big name preacher who knows how to put on a show and really entertain the congregation. He usually goes over his interpretation of evangelism and instructs accordingly in a way that just wows the audience. Then in a week he goes to his next venue (or back home) and he's done. He came, he preached, he left.



That's what I see a lot with agile and related topics. Many sensational people stand on their many platforms and evangelize for the cause. Most of which are consultants. And at the end of their contract they move on and spread their teachings to the next victims clients. Their words were all well and good and actually could lead to a good thing, but there was no practice, and usually when they go their methods go with them.



So I guess really my pretension isn't with the process of agile or becoming agile, but with the evangelists who go around preaching the good word but not doing much in the way of practicing what they preach. Since I'm a practitioner of learning by doing I need a doer to come in and do so that I can join in, not so much a teacher coming in to tell me how it should be.



Until next time

Les