Interesting Read: The Planning Fallacy

The Planning Fallacy is an essay by Eliezer Yudkowsky from Ramit Sethi's blog I will Teach You To Be Rich. The essay in a nutshell says that we're bad at estimating.
Estimation IMO is a crap shoot. If you hold me accountable to my forecasts I'll guess how long I think I can finish something then double it. That seems to come in right on time. It's never as quickly as I think it will be. There's always something that can be done up to the deadline.
If I can't just double a guess I prefer to use Joel Spolsky's Painless Software Schedules.

Talking to your architect

How do you talk to your architect if you are a project manager or developer? In my company there is a pretty clear division between architects and the people who work on projects.
In my role as a development lead I want our stuff done with the technologies that best suit the project.
Architects, they seem to just want to muck up our projects.
--Warning, griping ahead! To get to the useful stuff look for (MONKEYSHINES)
Our architecture teams are disconnected in many ways from our development teams. To the developers, the architects don't understand the technology at all. We read their reports on recommended technologies and wonder how they can come to their conclusions. To us, we see their technical recommendations and shake our heads, it's bad.
The typical architectural recommendation involves a commercial product or two, and the first open source alternative that they can find. The architects outline the strengths they see between the products. The point they seem to always hit is support, the commercial vendor 'supports' their product and the open source alternative doesn't. Support is important, and apparently looking at the source code isn't sufficient enough for supporting a project.
It doesn't help the cause that the company has some projects that were deployed on the JBoss platform that didn't go well. Many of the developers of those projects are now architects. If you ask them, the reason that the applications crash is because JBoss is unstable. Never mind the slew of null pointer exceptions and open JDBC connections, or the fact that objects are haphazardly dumped into a session, and that the session timeout is extended to an hour for all sessions to satisfy one single use case. It's the open source application's fault, not the application's.
What makes things worse is the same architects have the final say over what technologies developers use in their projects. If a development team believes that Java Server Faces is the best technology to meet the needs of a project and the architecture team hasn't approved it yet, well that development team needs to present their case to a board of architects and state the merits of that technology over any of the other ones that the architects have previously blessed, Struts for example.
Going through the process is painful and slow for the devlopers. Developers feel that the architects put the burden of introducing new technology into the company on the shoulders of development. There is definitely an adversarial an uncooperative element to the relationship between developers and architects in my company.
It isn't good.
One of the most frustrating parts of communication between developers and architects is that the architects don't really care about the same things that developers do. The ease of implementation or the ability to maintain a technology are more important to the developers who are doing it than the architects who haven't touched a line of code in years.
Probably the biggest point of friction between our developers and our architects is the architecture team's role in deciding what software can and can not be installed on our workstations. The architects decide what text editors, what IDEs, what debuggers, performance profilers, and other tools the development team uses.
The architects don't like open source tools and will usually forbid their use by developers. Architects also forbid the use of Firefox because it is less secure than Internet Explorer--their words not mine. It's statements like that that create contempt between developers and architects.
Our developers would like to see them try and develop a web application only using IE. There are a ton of excellent plugins for Firefox that developers can only use on the sly like Firebug, YSlow, and Selenium IDE.
Ok, with that said, you might begin to see why developers try to minimize their contact with architects as much as they can. With that said, I finally figured out how to actually communicate with my architects the other day.
(MONKEYSHINES)
Communicating with an architect requires that you understand an architect. Architects are concerned with long term visions and the direction of enterprise applications. They want to know that a technology is going to meet the needs of the business and will be expandable to adopt whatever initiatives they have planned.
If you need an architect to cooperate with your tactical needs, make your points focus on the long term benefits of your approach. Make whatever you really want incidental to the long term point. For example: if I want architectural approval for my team's plan to develop a project using Grails, I would want to focus on the ability of Grails to run on existing platforms, on the ability to easily add functionality to Grails projects, compatibility with SOA, and whatever else I can find out about their long term plans. I should completely skip the things that are important to developers: ease of implementation, syntactic simplicity, etc. They won't care.
Any good salesperson will tell you that you need to know who you're talking to and speak to them. Make your points important to the people with whom you are talking and you will find that your communications are more productive.

Master of Ceremonies

Ceremony seems to be the new buzzword meaning wasteful and inefficient practices that indirectly achieve a goal.
Ceremony has a special place in my heart. I grew up in a uniquely ceremony rich environment. My family was a member of a fox hunt club and my dad spent every opportunity fox hunting.
Traditional fox hunting dates back to the middle ages. At the time of its inception it served a purpose to kill foxes. Foxes are predatory animals that can wreak havoc on chickens, turkeys, and other agrarian fowl. At the time, the most efficient way to reduce the numbers of fox were to use hounds to hunt them down.
Fox, however, are not dumb animals, they are elusive and provide a particularly difficult challenge to actually catch and kill.
The practice of hunting fox turned into a sport enjoyed by those who can afford it. A culture and with it a set of ceremonies developed around the sport of fox hunting. There is a unique set of terminology, there are rules of etiquette, and there is a set of attire pertaining to fox hunting.
If you ask people who are involved with fox hunting in America, almost none of them will say that they fox hunt to kill foxes. Most will say it's a social thing, or they enjoy riding horses in the country, or it's the thrill of the chase and killing a fox is completely incidental to their reasons for fox hunting.
Most of the ceremony of fox hunting exists as a relic from a practice that served a purpose. The attire, for example. Fox hunters wear a stock tie. A proper stock tie is an 8 foot long piece of fabric that is worn around the neck and secured with a pin. The purpose of the stock tie was to serve as an emergency bandage, sling, or other purpose in the field. Modern stock ties are approximately the same length as a neck tie. The need for that type of first aid equipment is satisfied better by more modern field dressings and communication devices.
Many aspects of fox hunting no longer serves its originally intended purpose.
I argue that all of fox hunting is ceremonious and not essential to whatever reason people say they do it. It clearly isn't to keep the American red fox population in check. There don't pose any significant threat to agriculture like they used to. The hunt club that I grew up in used to stock foxes in the countryside and leave store bought chickens to keep the population up. Still to this day, I do not believe that the club has killed a fox in their current location. There are coyotes that do that.
I argue that fox hunting is ceremony for the sake of ceremony. There is nothing beyond the ceremony that a fox hunt has to offer.
People who fox hunt today are hunting to participate in an ancient ceremony. They don't do it for the purpose of achieving a goal. There are other, more efficient, ways to achieve whatever it is that people say they achieve when fox hunting.
Fox hunting is a wasteful and expensive hobby. Juxtaposed with all other hobbies, which are clean, efficient, and cheap. People enjoy hunting. They aren't stupid per se. I don't enjoy it, but who am I to say what people should and shouldn't do for enjoyment. It is rife with ceremony, which from my point of view is the essential purpose of modern fox hunting.
What purpose does ceremony serve? It clearly isn't functional. Or is it?
No, ceremony does serve a purpose. Good ceremonies are a way that people come together on an emotional level. They are the remnants of that which people remember and relate to. Ceremonies are how we express traditions.
There are good ceremonies, but there are also bad ceremonies. There are a ton of bad ceremonies. All the things we do in the office that are indirect to achieving our goals are ceremonies. Those ceremonies do more to divide and frustrate people. We should find a way to light them on fire.
There are also good ceremonies. The silly things we do do serve a purpose.
Before we cast all ceremonies as bad and unnecessary. We should look to differentiate the necessary ceremonies for the unnecessary ones.

Meet the user

Yesterday I had the opportunity to sit down with one of the users of an application I helped build last year. The project was in many ways painful to me and rewarding.
(Warning! Long story ahead! To get back to the user skip down to the bolded word monkeyshines below)
The project was painful because the charter of the project was to replace an application that the users did not like with an application that was to be as close to functionally and visually identical from the application that was to be replaced.
That's like going through an unhappy marriage, getting a painful divorce, then marrying her younger sister. It's worse than that, it's seeing all the mistakes that were made on a previous attempt, knowing they are there, and then doing it all over again. Let's start with how this happened.
Well, the goals of the project were defined by people who didn't have any stake in using it. The director who made all the decisions used the application as a reporting tool and not as a tool to update records. Her use case was to look things up and see as much information about those things at once as possible. In fact, she demanded that 26 columns of data be displayed on a page and that paging not occur. The number of rows that could appear could reasonably reach around 5000 rows. That's 130,000 data points.
These requirements were set the last time the team created the tool. These requirements had been set 5 years prior to the project I was in. The UI was created by a bunch of C programmers and mainframe programmers who were making their first attempt at creating a Java web application.
The developers violated a few tenets of my base level rules for web applications: they were opening JDBC connections within scriptlets, they overloaded buttons to add unintuitive functionality, instead of improving query performance they came up with the worst Ajaxian hack I've ever seen.
The hack was to handle when JSP pages would timeout in a browser before the response was returned from the server. It happens from time to time, especially in synchronous web applications.
The hack worked like this. The request was sent to the server. The server spun off threads to perform queries against the database. When the threads were finished they set a static variable on the thread class--safe I know.
The JSP would follow the following logic. It would load the page that rendered the results of the query. It would then check the static variables on the threads to see if the information is ready. If it was ready, the information was rendered on the page. If it wasn't, and it usually took over 5 minutes to be ready, the page would immediately reload.
The resulting UI experience was for the page to flash like crazy and the clicking sound you get in Internet Explorer when you reload a page. Fortunately for the people whose job it was to perform this application's business function, there was a pretty well made application that did the same thing that was made with them in mind. They griped that the new tool was not fast enough. They probably should have also complained that the UI design of the tool was horrible. The users just continued to use the old tool and refused to let it be retired.
The new tool that I worked on was to replace both the old tool and the old new tool. The director who funded the project left no room for training and very little for business requirements. The requirements were simple, make a new tool that works exactly like the new old tool, not the old old tool, and make it faster. Any usability improvements and you'd need to get a variance from the director.
I should mention that this director is one of the most unpleasant people I've ever worked with. At least that is the reputation that preceded her. She was by no means dumb, she held a doctorate in one of the most demanding fields--more difficult than an MD. She was known for shouting at people in meetings and trying to intimidate them. If she didn't get her way or you weren't moving fast enough for her she'd go right over your head.
I experienced a little bit of this when she found a bug while our project manager was on her honeymoon. It would have taken many of us out of our comfort zone to get a change into production with the PM gone. I tried to suggest a workaround that I thought was pretty reasonable, it required an extra step, but nothing too onerous. I sent the step by step instructions and an explanation that putting a fix to production was risky at that time and difficult. I heard nothing back for a day. The next thing I knew we had an emergency ticket demanding that the fix be put in immediately. No reply to me, just a demand straight up my chain of command.
That was her being nice. Weekly meetings before I joined the team, when the team consisted of people who were involved with that early attempt at a web app, were the stuff of legend. One contractor on the team and she would get into shouting matches each week. It could have been a cultural thing, these were both Indian women, but they really knew how to dig into each other. I never personally witnessed any of the things that people talk about in happy hours.
I think it's clear to state that the flow of usability enhancements were tempered more to a drip. Suggestions that would improve performance were even carefully crafted because she may go ballistic.
With that in mind, we went forward designing a back end that worked in a way that was as clean and sound as we could make it. We took all of the functional business logic out of the UI and put them in a respective server side service or model class. We made a very sound application on the back end. Something that I am very proud of. Considering the requirements and the bar that was set by the old new tool I thought we made a huge step forward.
It wasn't as fast as something that would could have created with collaboration from the users, but it was pretty good. Instead of 5 minutes and a clicking sound, we'd see a range of between 1 and 45 seconds depending on the parameters with no clicking. 45 seconds to pull a couple thousand rows, that's not too bad considering our constraints. The performance was deemed acceptable by the director.
The old new tool was decommissioned as well as the old old tool. Now users could only use the tool I worked on.
(Monkeyshines)
Which brings me to yesterday. Yesterday I got to sit down with one of the most frequent users. It pains me to meet with her because I can see the results of the compromises that were made because the funding party had no interest in the users. It pains me because we did not meet with the users while we were developing this application. We funded a year of work for a team of five developers, two testers and a project manager, but we couldn't bother to meet with the people who were actually going to use the product. What a waste.
It wasn't all pain though. I was able to learn more about how she uses the application and get a list of her biggest complaints. I'm going to try and funnel those into our summer internship program. I think making small enhancements will be a great opportunity for our interns. The user also learned a lot from the experience, I was able to share a few shortcuts with her, ctrl + f for find, ctrl + z for undo, ctrl + a for select all. I was also able to explain why it take a month for anything to get fixed--thank you Sarbanes and/or Oxley--or the people who interpreted that legislation as it pertains to business software development. I told her how to submit enhancement requests and that I'd do my best to get interns to help out. I also explained the constraints that we had to deal with in providing the tool. I think for her, she saw that the people who made the application that she was frustrated by actually want to provide something that isn't painful for her to use. That we want to give her something that is better. I gave her a sense of empowerment by telling her about my intern plan. For me, well, I feel better about the improvements I make. I know there are results for my work. Although my company tends to silo the people who make the software from the people who use it, we all benefited from the experience. By meeting my 'customer' I now have an emotional attachment to my work. I know that there are effects to my actions and that what I do is important to somebody. I recommend that if you have the opportunity to meet whoever it is who uses the products of what you do, be it a coworker, a customer, or whomever that you take it.

It is a gift to be simple

One of my favorite shows from the early 2000s is a British show, Junkyard Wars. It was called Scrapheap challenge there. The premise of the show is there are 2 teams tasked with building a specialized machine out of items in a big junkyard to help complete a task. The teams consist of 1 expert and three regular team members. A task could be building a machine to knock down a wall.
This was my favorite episode from the UK series.
One team made a hydraulic set of jaws on a manual crane, which they called The Muncher. The Muncher was painted up like a dragon and just ripped through the brick walls. The bricks just crumbled in its massive jaws. It was awesome.
The Muncher's opponent was just a battering ram that was set on a couple of A frames. It was just a really heavy gas pipe with a reinforced head and filled with lots of weight. The ram team only made it so the length of the cable holding the ram could be adjusted, otherwise it was just a hanging hulk of heavy metal.
The competition was to knock down three progressively stronger brick walls: 1 brick thick, 2 bricks thick, and 4 bricks thick.
In the first part of the race the muncher went straight through the single tiered wall. The bricks were pulverized by the muncher's mighty jaws. The second wall didn't pose much of a challenge either.
The battering ram took a little more time. It took something like three or four carefully placed hits to knock down the first wall. The second took a bit more time.
Meanwhile the muncher was chewing up bricks and knocking the loose ones aside with its big head. The motor was rumbling to feed the hydraulic pump. It was just a mean brick munching machine.
At the third wall, the muncher reached a bigger challenge. The wall was too thick to just munch away. The jaws of The Muncher could only pull a few bricks at a time. As the Muncher took on the thick wall the hydraulic pump stressed so much that its weak points, the hose connections, gave way and the muncher turned into a fountain of gushing red hydraulic fluid.
Meanwhile the battering ram team refined their technique. They made steady progress through the second wall, then moved on to the third. By the time they started on the third wall the ram team knew how to take it out in an efficient and effective way.
The muncher team resorted to swinging the muncher head on the crane swivel into an ineffective wrecking ball.
The ram team won.
This is the trend of the Junkyard Wars. The team with the most simple designs fared much better than the elaborate designs. Each layer of complexity for the junkyard machines introduced another opportunity for a breakdown.
In software, and software development, the principle remains the same. Less is more. Complexity in software is like moving parts in machines. The more complex something is, the more opportunities for it to fail. There's a measurement of complexity in software called Cyclomatic Complexity. Simply put, it measures the number of test cases it would take to test all paths within a unit of software. If one case can cover an entire method, that's very simple. The more cases it takes to cover the method, the more complex it is. For a class, people say that an index of 10 or less is ideal, sometimes classes have indexes of over 100, over 500. Those are the classes that are going to give you your problems.
One class that gave me fits was a 10000 line java class that I inherited on a job, I'll call this class SOSOM. I owned SOSOM for a year. SOSOM kept me busy and gave me lots of experience debugging complex problems. It also kept me away from keeping up with the industry.
SOSOM had one method that was over 2000 lines long. That 2000 line long method was the most frequently invoked method in SOSOM. SOSOM was also the most frequently invoked class within the largest Java enterprise application at the time.
SOSOM was critical to this enterprise application which many companies relied on. If the application failed, production lines stopped and money was lost. If SOSOM failed, the application failed.
SOSOM didn't start out the monster it was. At one time it was just a complex implementation of a service. Over time, features and capabilities were added. SOSOM was never refactored, features and specialized cases were added by different people and the complexity grew.
I don't work there anymore, maintaining that beast took too much out of me. The class itself was a big effort. The other element of complexity was the version tree. SOSOM is housed in a clearcase code repository. The number of versions for SOSOM was around 400 when I left.
There were three major versions of the product for which I was responsible. There were also about 20 point release versions that I also needed to watch. At any one of those points I could be tasked with finding out why a customer's system was failing.
SOSOM is The Muncher on steroids. I would have preferred a battering ram.
The irony is that SOSOM's purpose is pretty simple. It could have been a battering ram. Even with the extra features it could have been a simple implementation.
When I design things now I look to build battering rams. Simplicity is a gift and unnecessary complexity is a curse.

Theater review: Third

My wife and I have season tickets at the Guthrie Theater. I love having them, we get the same seats for each show. I love the seats they are perfect for getting to the bars at the intermission and after the show. Pro Tip: after your show, go to the bar and have a glass of wine or coffee, you'll avoid the traffic congestion in the parking lots.
Despite my initial reservations for going I have to say that all of the shows exceeded my expectations.
The latest show we saw is Third. It's a humorous play about a liberal English professor, Laurie Jameson, who is troubled by a student who fits her ideal of all things Republican. Woodson Bull the Third, hence the name, fits her image of a young George W. Bush/Donald Rumsfeld type: white, straight, athletic, and cheerful. He also is a good student. Too good for her to believe, so she accuses him of plagiarism.
The dialogue is fantastically funny. There were some great laughs for most of the play. They did a good job keeping the funny coming. Word of warning, there are a few bombs dropped in the play, if you're offended by profanity, well I would advise against your seeing the play. Also, you should really question why profanity offends you, seriously. Not something to bring the young kids to. Also, if you consider taking small children to a stage theater for anything but a kids show, you should also rethink what you are doing.
As a white, straight, athletically inclined, happy male from a conservative house who happened to get an English degree I could relate to the play. Laurie Jameson's interpretations of King Lear reminded me of my Shakespeare class under Miriam Gilbert--the Shakespeare not the interpretation. I would love to hear her reaction to Third, I think she'd laugh like crazy through it.
The acting was excellent per usual. I enjoyed the set. It was a bare stage, for each scene the set furniture seemingly would glide onto the stage without a visible means of locomotion. The set walls had images projected on them. Between scenes, there was an enjoyable set of remakes of songs from the 60s and 70s. My favorite was a string quartet playing Jimi Hendrix's Purple Haze.
Overall, I thought the play was thoroughly enjoyable. My wife thought the ending was a little too clean for her taste

Get it right, then get it...

When I was in college, university for you non-Americans, I worked a few jobs as a cook in restaurants. The biggest challenge in starting a cooking gig is to learn the menu, the cooking techniques, and how to prepare the food. Getting trained as a cook takes a good chunk of time and it's a daunting task to try and keep up with the pace of the restaurant and your coworkers. You usually start out as the slowest person who knows the least. You come in and know almost nothing about the business and then there are people making food at lightning fast speed flipping sautée dishes and chopping food like the cooks do on tv. It really makes the job a challenge.
The places I worked were distinct in their menus and kitchens, but in each of the places that I worked we had the same mantra to trainees: Get it right, then get it fast.
If you focus on making the item what it should be, and stay to that standard, you will produce it faster with practice. It takes a bit of time and it isn't exactly clear when it happens, but you get good at what you do. It's like one day you are that person flipping a flaming dish in a sautée pan--while not spilling a martini glass in the other hand, and chopping veggies quickly with a knife.
When I worked at the lesser known Jimmy John's, most of us who had been there a while could make a full sub faster than it took for a customer to walk to the end of the table.
Get bread, slice bread, pull bread guts, measure then spread mayo, fill with lettuce, add tomatoes, add meat, add cheese, fold sandwich, wrap, tape and give to customer.
We had learned the motions so well that we didn't need to think at all, the actions flowed out of us. We learned what the sandwich should be, then we learned how to do it as quickly and efficiently as we could.
The same approach works for developing software. If you focus first on delivering software that gets the job done, you can then work on making it fast, flexible, or whatever it is you want it to be, in addition to correct.
In the agile approaches, they call it refactoring. Refactoring is achieving the same results in a piece of software in an improved way from the original.
If you first lay down a baseline that achieves the results that you want, you have something that at the very least is correct. You can also build deep integration tests around that base and include it in an automated testing suite. If the tests are good, team members check in code in as granular segments as they can, and you run a continuous build server, the team can be confident that efforts to improve code will not cause any breakages that go unnoticed.
You then can work on making it better. I would suggest involving others in this stage, pair programming or small group design sessions will yield more than an improved piece of software. In my opinion, this is where people really grow as mentors and as programmers. Mentors are able to see things in others' code and share their experience, the learner is able to learn from the other. What happens after a group refactor is more than just making better code, you have people who learn from the experience who are more likely to write the code better the first time the next time they encounter that situation. There is also a good chunk of cross training in different parts of the product.

Favorite Tools: Beyond Compare

Diff tools are awesome. If you are not using a diff tool you should really consider giving it a try. My favorite diff tool is Beyond Compare.
I like BC because it does more than just compare two text files. BC will also compare archive files intelligently: zips, jars, wars, ears, etc.
It is what I would describe as one of the most mature software products out there. There is a lot of polish on it and it seems to be able to be integrated with just about anything. BC has one of the most generous shareware licenses out there, it's a 30 days of use license. You get to use it on 30 separate days before, well I don't know what happens because I bought my license, $30, after about 5 days of use.
One of the things I really like about BC is it has a very clean interface for showing the differences in files. It has nice color coding and doesn't do anything fancy with alignment.
BC has saved me a lot of stress by comparing one version to another.
We had a project that was at risk of missing its deadline. A few hours before we were set to deploy we found a set of regressions. All I knew at the time was that the regressions were not in the build three days prior. I was able to load a version tree from three days prior and the current version and perform a diff of the entire source. Within minutes I could review all of the files that were changed and the lines where they were changed. We were able to find the source of the regressions very quickly.
I use BC with my source control tools. It integrates easily with Tortoise CVS--not my choice to use CVS--and it works well. One thing I like to do before I check anything into source is review it. With Tortoise and BC this is easy. I can right click commit on the source folder and Tortoise will list the modified files. I can right click on each of them to see the differences in BC. BC will let me edit the diff directly, so for example if my indenting is off I can take care of that in the diff, or if I commented out some code I can remove that commented out code. The net result of diffing your submissions is you are more aware of your submissions and there are less unintended code commits.
A surprising benefit of BC is it can be used to edit very similar files. I did a recent project in Spring Web Flow, and found BC to be a great tool. Web flow is a framework that, among other things, features flows, xml documents that describe the different paths that a UI can follow and the logic that gets performed along each step. In my application I had 5 different flows that were structured the same way, but with different business logic.
Beyond Compare helped me with the process. Normally, when I'm working on multiple files that are pretty similar with minor differences I would need to be very careful about making changes, because it's very easy to lose track of them. With BC, I didn't need to worry about those things, I could experiment away with one flow document and then quickly propagate the net changes to the other similar documents through a diff. Any minor changes that occurred could be hand tweaked with inline editing.
BC is awesome. There is no reason why anyone shouldn't at least give it a try.

Goodbye Youtube

Streaming/Media is the newest category of forbidden sites in my company's crusade to get us off the web. Streaming media from video.google.com is ok though.
In my opinion, blocking web content is a bad idea. We can all appreciate why companies do this. They want people to spend their time at work, doing work.
My company has a lot of employees who are hourly and I think that they set the filters with them in mind. I'm sure I would look at people doing faceplants on youtube all the time if I were in a call center.
My problem with this approach is that it is executed with broad strokes. There is a growing list of news and technology resources that I am unable to reach while I'm at the office. There was a technical paper about how casinos implement their security systems, blocked for gambling. Postmortems for video game projects at Gamasutra, blocked for video games. My favorite online javascript stopwatch site--sweet tool for doing really simple UI stopwatch tests, blocked for games.
I think the bigger issue is the message that the company sends to all employees. The message I hear is, "We do not trust you." In my opinion, this is the only thing that the company succeeds at with this approach. Any sufficiently motivated individual is going to find a way to do what they want regardless of the barriers that are put in front of them. If people are going to goof off at work, it doesn't matter how many distractions you take away, they are going to find ways to escape working.
Getting into an arms race between the company and the slackers is a losing proposition. People who are motivated to work are going to work and those who aren't motivate, well wouldn't you be better off having a person who is motivated in that position.
Investing time and resources in preventing people from goofing off is expensive. It can't be done well. It will usually penalize and hurt the morale of the people who are motivated.
My solution, let people do whatever they want with the Internet and judge them by their results.

Find Null Pointer Exceptions Fast

Null Pointer Exceptions in Java are frustrating. They are the snipers of Java software development. NPEs can kill an application, well a poorly written one, and leave little trace of their cause.
A null pointer exception occurs when a method is invoked against an object that has a null value. Java seems to completely lose its mind and just print java.lang.NullPointerException and a class name. There's no stack trace and there's no line number. It's a bummer. You've been sniped by a NPE.
Like any good sniper, a NPE hides itself. You can tell the direction from where it came and that it happened, but that's about it.
The best way to deal with NPEs is to prevent them from happening. The way I try to do this is to assume that someone is going to pass a null value as one of the arguments and I assume that null could be returned by any one of my method invocations I'm pretty well covered.
Another trick I like to do is to flip values in equals methods, for example, I 'll go:
"value".equals(variable) instead of variable.equals("value")
by invoking the equals method on the String constant a NPE will never occur even if variable is null.
Luckily we all write awesome code so this never happens, but when we need to look at other people's code to find them I use the following technique. It's a divide and conquer technique that has served me well.

1. Make it repeatable--find a way to repeat the use case consistently
   
2. With your favorite debugger--use Eclipse if you don't have a favorite
   
3. Step over each line until you hit your NPE
   
4. Once you hit the NPE, put a break point on the line where the NPE occurred
   
5. Uncheck the last iteration's last good break point.
6. Rerun your use case
7. Step into the line where the last NPE was thrown
8. Repeat from step 3 until you find the cause
   

In a few iterations you will find the method and the line where the NPE is triggered.

Better Business Requirements

Some of my developer colleagues are in a software project that is a total mess. They are very frustrated that the business users keep changing their minds between when they set their requirements and when it comes time to make a release.
From my distant view I can see a couple of things that are not working in their favor. They are not communicating well. If the software development team is not meeting the business users' expectations, then there is a communication problem. The business users say one thing and the developers do another.
I think a lot of this comes from my company's process of setting business requirements. It puts the project into business terms that are not native to the business process or descriptive to software. The process of creating requirements should be an understanding of what the users want and what the development team can deliver. If you set the requirements and the expectations in visual terms, i.e. pictures and simple diagrams, then people will have a concrete image of what they want. When the delivery of the software comes around, there will be far less surprises.
The second thing that I notice is the development team kowtows to the business users' demands well after the requirements have been made The requirements are effectively open until release time. This has nothing to do with agile methodologies, it has to do with business users who are not accountable for their actions. The business users who are setting the requirements are also not funding the project. They have no accountability for the hours that are spent creating the product.
When the business users see the software when the development team is getting close to delivery the release is not as abstract as when they specified it. They then can see that the product is not what they wanted. They let the development team know that it is unacceptable and they say what they want. It's like the initial design and development stages are really just a prototype and the user acceptance stage is when the real requirements get set. This puts a tremendous strain on the development team because the release date doesn't move. This puts absolutely no strain on the business users though, because the project isn't coming out of their budget. They realize absolutely no penalty for vague requirements.
I would propose that instead of giving the business users a free pass that the development team stops allowing changes in the business requirements after they are set. Any changes after they are set go into the next release. They will deliver something that the users don't want, but the users will then have an incentive to give thoughtful requirements during the requirements phase.

Very interesting interview with Ron Burley

The Consumerist has an excellent interview with Ron Burley, author of Unscrewed, The Consumer's Guide To Getting What You Paid For.
This guy is very smart. I like his approach to dealing with customer service issues.

Real or Fake?

Ok, part of me thinks this movie is fake. The production quality of this movie is horrible, but it's awesome in its own way.

Excellent read on the divisions between corporate management and IT

Today's Wall Street Journal contains How to Tap IT's Hidden Potential.
This is an excellent view of many of the issues that I've notice within my own company. One of the key points that the authors make is that there are differences in the language and cultures between IT professionals and other company leaders. A company that is going to realize more potential is the company that lessens the differences between IT and the rest of the company.

Conflict

There are a couple of conflicting forces both pushing me away from my current company and keeping me in. I wish it were as simple as working for a crappy company that I don't like. Lately I've gone through a range of positions from wanting to leave at the earliest opportunity and wanting to stick it out. Both sides have valid points.
Should I stay?

• My job security is good.
• My benefits are adequate.
• I am happy with what they pay me.
  
• The work experience is excellent.
  
• I like the view from my office.
  
• I enjoy the company of my coworkers, however I don't get the opportunity to spend much time with them.
• The managers in my area are excellent.
  

Or should I go?

• As a group, we're overworked. There is far more to do than we have the people or the hours.
  
• My company is complicit to wasting our time. This is one of the most ironic aspects of my job at this company, they will spend $20 to avoid wasting $10, but they don't seem to mind that having us wait on resources and not be able to do our jobs also costs the company.
• The hardware my company provides is weak--this is an extension of the previous point. There are a few low cost things the company could do to improve productivity and people's experience at work.
• Departments make decisions that affect everyone without thinking it through. Take facilities and security for example. They recently created a policy that changed the time that the front door to the building is locked, from 6:00 AM to 7:00 AM. They posted this notice outside the door while the temperature was below 0. To enter the building before 7:00, the guard would need to let you in. This usually works fine, but what about the time he's in the restroom? Did I mention the temperature at that hour can be very low, we're in Minnesota. Also, what value does keeping the door locked early have? It only inconveniences those of us who get to the building early and gives the guard one more thing to do.
  
• Here's another one, they put speed bumps in the parking ramp in the worst possible places, right below the massive concrete beams. The beams are the lowest points in the ramp, so those who are unfortunate enough to drive high clearance trucks get to scrape their roofs on the beams when they didn't before.
• They write us parking tickets, no fee, when our cars aren't parked to their satisfaction. There are compact spaces, that seem to be randomly placed throughout the ramp. They are about a foot shorter than the regular ones, that is, they have a line painted a foot in from the end of the side lines. Many of these spaces also have a big standpipe or pillar that effectively cut a good foot and a half from the other side too. Ok, here's the kicker, you not only need to keep the tires within the compact box, you need to make sure that the entire car is within the box. Otherwise, you have a sticky nastygram attached to your vehicle.
• Another thing, they put these signs for the compact parking spaces up in one of the worst ways I've ever seen. They secured metal signs from the roof. The bottom of these signs ar about an inch or two shy of six feet off the ground. They are also painted a dull taupe color. I've heard stories of people banging their heads on these signs. When people complained, the people responsible for them, in so many words, said tough.
• Ok, one more gripe about security. We have badges that expire every year. They won't let us in, if our badges are expired. I learned this when I came in at 6:30 AM on my one year anniversary. I had to either wait for my manager or see if my director or VP were in so they could wave me through. My manager couldn't ok me over the phone. What you need to do is find a form out on a shared drive and have it filled out each year. Did they hire me to write software or did they hire me to fill out forms?
• Forms, forms, forms! This company operates under the paradigm of an old insurance company or accounting firm. There are forms for everything. The forms are Word documents with a bunch of fields and check boxes. A form must be attached to a ticket to get accounts on applications and computers, to get software installed(it is forbidden to install anything yourself), or to make a change request. The forms are written so that auditors can trace everything. A form must be filled out for just about everything, then the necessary approvals are needed for them--good luck if someone's on vacation. If you miss a checkbox or field in the form, your request will be denied. If you fill out an extra value in your form, your request will be denied. If you fill everything out correctly, you form can still be denied. And by denied, you get an automated email that says your request was rejected. There's little or no information who to get in touch with. It also takes about two to four weeks to get a request through. All of the information that is captured in the form could be put on a form based web application. The web application could perform validation of the input and avoid that wasted 2 week reject cycle. The web application could also print out a MS Word document that contains all the request information and put it in the same place the current form goes.

Ok, I could go on, there are plenty of other things that annoy me. I think the repulsion is winning right now. My plan is to still wait it out until the summer.
It's odd though, it's not like it's all bad. I am pretty happy for the most part. Given enough time, I think that things will improve, but not fast enough. I think that I can do better.