I have a question regarding testing internationalized products. My concern is that we are all developing and testing on English versions of Windows XP and Windows 2003. We change the regional settings in the control panel but I have a nagging feeling that we are missing something. Are there peculiar idiosyncrasies between versions of windows built for specific locales? Basically, if we continue on this path should we expect to see potential major problems later on? If we want to sell our product in China should we have a dedicated testing system that is running a Chinese version of the operating system?

About seven months ago I had written that the company I work for was undergoing major changes by moving to a Agile development methodology. Well I've gone down that road and I'm happy to say that I'm still here but this past half year has been a terrific ride. The company with its 500+ developers has jumped into the agile process head first and are now looking back feeling that the move had been a fantastic success. Though the data is still being collected the software scheduled for release this year contains the features we wanted with the quality we where striving for and in the timeframe we had set.

Before moving to agile, and part of the reason for the move, was that it was taking longer and longer to release our software and the quality (read number of bugs) was rising and rising. Getting the software out the door before the move was riddled with unpleasent surprises. Now we have a better idea of where we are then ever before.

That's not the only changes. During the past 6 months I was acting principle engineer for a feature to be developed by my group. We embraced the Agile method, delivered the feature, I've been promoted. Recently I have been asked to join a new group within the compnay to act as a principle engineer for a high-profile change to the product.

Needless to say I'm pysched but after the move I've encountered some new unpleasent surprises. The new group is in disarray, there is not clear chain of command and the focus is lacking. The current set of employees are already showing the early signs of being burnt out and panic is evident in the air. I've made attempts just this past week to address these issues and the group has taken a step back to re-evaluate oru situation. It's a good start to resolving some of our problems. But even that said I am not terribly positive. If I could move back easily to my old group I would have to admit that I would be very tempted. But the situation here is dire but it is and we need to do the best we can. I'm hoping that I can keep my head enough above the shit to update this blog more frequently. At least post something before September ;).

As I mentioned in my last post my company is moving torward an Agile Methodology. The primary reason for the switch from the waterfall method to an agile one was attributed to the increasingly complex software we are producing. This was incurring longer and longer release schedules and an increasing number of defects.

I for one have been looking foward to learning all I could about Agile and I welcome the change. But I understand there are going to be many growing pains along the way. And the pains have already begun. Now just because we are introducing a new methodolgoy doesn't mean we can stop operating as a revenue generating busienss. So up to this point my team has been planning the way we normally do. This is mainly because we simply did not know what to expect. It's sort of like being in limbo, you konw that there are going to be major changes coming over the horizon but you don't know exactly when or how those chagnes will manifest. So, to the best of our abilities we began to design and estimate what we where going to do for the feature we are responsible for.

Now having been to the introductionary training program the work we've done is almost useless. Our project plans and estimates can basically be trashed. The detailed document artifacts describing the designs have very limited value given the "evolutionary design" we will be practicing. But we still arn't there yet and this limbo continues. We have been given a taste of what's to come but the main course has yet to be served.

The next steps are going to be training workshops for the various roles. And while these will help answer a lot of questions they are causing their own problems. This is because not eveyone on the team has the same training schedule. For example the developers are having their training this week but the project manager is training next month. So while we are trying to get our jobs done half of us will be thinking in the Agile way while others are still doing things the same old way. This is going to cause great conflict in my opinion and a lot of time is going to be wasted. How can we take the first steps like building the stories when a major part of the customer community deson't even know they are the "Customer Community"? Our kickoff for iterative development starts in two weeks and we have a lot of work to do beforehand. Like development stories for one. How can this possibly occur with any accuracy without them?

So I'm stuck in a bad place while this chaos proceeds. The next month is most likely going to be total anarchy and will mimic on a larger scale the chaos that occured during the introductionary training. I haven't talked in detail of the traning itself but suffice to say it was left with a horrible impression of things to come in the short term. By the feel in the room and the questions asked there appeared to be a lot of doubt. In that training class we went through a comical simulation of what the agile process is. It was a laughable mess with people just lingering around with no idea of what to do. It was poorly executed to say the least.

And I'm back to the same old question. What the hell do we do now knowing we don't know what we don't know. I keep coming back to the same conclusion, proceed as best we can. We have an good idea of how we would do things using our old methodolgoy so for now we will proceed with that. I'm thinking that we can at a later point in time take what we produce and consider it as "legacy code" that needs to be refactored and integrated into the new scheme of things. I don't see any other choice given the overall deadlines for shipping.

I'll post again after the intensive developer training sessions. Hopefully things will not look so dismal then.

There has been a lot of changes occuring at the place I work these days. What first started off as rumors and water cooler discussion has finally taken shape. Several weeks ago it became apparent that the Agile methodology was coming to my workplace. And just last week we had an offical sending off in terms of an all-hands meeting to discuss the coming changes. At that meeting we discussed the reasons for the change but not the actual change itself. This week a bunch of us are in training; or a boot camp on how we will be implementing the Agile methodology. I will try to capture this tansition from a traditional development environment to this new Agile method here so stay tuned.

Software patents are confusing. Call me stupid but I don't think I'm alone in this respect. By confusing I don't mean the whole this is my idea and you need to respect that part but rather what defines something as being intellectual property. For example the infamous patent that Microsoft has put on the todo list in IDEs. Yes I know it's old new but I'm not going to rant about that particular patent but rather use it as a reference point for discussing my angst with software patents in general and what actually defines something as being intellectual property.

So, let me try to get a handle on this. In essence the todo list patent covers the ability of placing comments into source code that are then used to generate a line item in a todo list. There is more to it but that's the heart of the matter. Now what is actually happening here? Microsoft is saying that todo lists that are driven by the code belong to their intellectual property. Is that correct? Now they are not patenting todo lists, nor source code but rather the idea that you can build and manage a todo list from source code.

Functionally what's going on? Adding text to the source code file is used to populate a control that the user can utilize. Well isn't that just about 90% of what the IDE is designed for? Why doesn't someone patent the tree explorer of source code? You know that panel that is usually on the left of right that you can use to manage your source code. You type in code the tree is automatically generated you click on an entry and you are magically whisked to the code segment you clicked on. What about annotations in code. Shouldn't the first company that came up with the idea that you can put annotations into code that are then used to generate documentation patent this idea? Shouldn't the creators of Eiffel or whoever came up with this first get on it?

What defines something as being intellectual property or not? The criteria for this eludes me and appears to be rather vague. Why doesn't Sun patent the idea of using a virtual machine to run an interpreted language to achieve software independence of the underlying hardware? If I can't use a todo list in my java IDEs then hell that whole CLR thing belongs to us.

For the past 6 months with the exception of two weeks I have been strictly working with Java. Even beyond this for many years I have considered myself a Java guy. Well now that the worst of my current project looks to be behind me I'm thinking it's time to expand my horizons and pick up something new.

I have had an affectionate relationship with Java for many years now and will most likely continue to work with the language for years to come. And I'm not saying this because I fear that the end if near for Java. But rather that as the years progress I don't want to be that guy that has nothing else to fall onto if times change.

So the question for me is do I dive back into .Net? Should I try Ruby and play with Ruby on Rails? Or how about the little know Water project? Speaking of Water there is a user's group meeting in boston tonight. But looking at their code samples makes me hesitate. Man that is some ugly stuff but hey it might be quite useful and extradionary. I hear that Ruby on Rails supports AJAX which is another techonlogy (composite) that I want to check out. And there are many more. The good thing about this decision is that there are so many choices. The bad thing is that there are so many choices.

Check out http://javadocs.org/. It allows you to search the javadoc api.

I actually was on a team that built a parametric search engine for the core api for the new http://java.sun.com/. It was built using rdf and searching would return not only a class but also all references to that class rank accordingly up to a configurable maximum number of results. The results would provide the entity name, type (class, field, method), package, and file. Open a result would load that file highlighting all occurances of the searched for word. You could also limit the the results to particular classes, or you could search for only methods or fields. rdf and the triples it represents performed nicely in this building of relationships.

But this is all moot the prototype was canned after a useability study showed there was no interest. I wish they would bring back as I think there would be a lot of uses for such a tool.

it would have looked like:

I was on the phone this morning interviewing a candidate for several openings that we have. My goal was to simply determine his technical expertise in Java. The conversation started off promising, progressed to bad, then became horrible and concluded with a hilarious ending.

For the first fifteen minutes the candidate was doing a great job describing at a high level the architecture of the last project he was working on. His descriptions of the components involved how they worked and interacted where fantastic and I was feeling pretty confident at this point. So I steered the conversation onto more detailed discussions of java, which I have paraphrased below:

Me >> "I'd like to determine your level of expertise in Java so let's discuss that in more detail. In the Java API there is a package called 'java.util'. Could you explain to me what it is used for?"

Candidate >> "java.util?"

Me >> "Yes in the Java API the packaged named 'java.util' could you tell me what its general purpose is?"

Candidate >> pause, "I'm not really sure."

Me >> "You know the package in java that has the collections"

Candidate >> "I've never worked with that before."

Me >> "You've never worked with a Vector, ArrayList, HashMap, HashTable or any other collection before?"

Candidate >> "No. I don't think I have"

Me >> "Ok, you should really take a look at the classes in that java.util package. They have a number of useful features like storing objects into a 'collection'."

Candidate >> "I've never had the opportunity to work that them before. I can talk about my Struts experience, would you like to hear about my Struts experience?"

Me >> "No, I'd like to discover more about what your level of expertise in Java are. In Java how would you convert a primitive into an object?"

Candidate >> pause ... incoherent mumbling ... "I don't know that."

Me >> "You've never taken an int, character, float, double and converted it into an object before?"

Candidate >> "I've never had to do that before. I'm not sure how I would do that. But I can talk about my Struts experience."

At this point the interview has entered the horrible stage. I'm figuring that I should end it but I was taken aback by the fact that he was doing so well in the beginning. I was thinking that maybe he didn't understand the question on primitives. I was determined to find out if he really didn't know:

Me >> "Let me ask you this, Imagine that you have an array. You've worked with arrays before right?"

Candidate >> "An array, yes I have."

Me >> "Ok, well imagine that this array is an array of Objects. You have an int and you need to put that int into the array. How would you do that?"

Candidate >> "That depends on what type of array it is."

Me >> "It's an array of Objects."

Candidate >> "Objects?"

Me >> "Yes the class Object. The class that is at the top of the class hierarchy. The one that all other classes extend from. How would you put an int into an array of objects."

Candidate >> "I guess you would convert it."

Me >> "Yes, but how would you convert it?"

Candidate >> "I'm not sure."

I'm now convinced he has no idea what I'm talking about. It simply amazes me that someone could go on and on with a sufficient amount of detail on the architecture of a project and yet not have the slightest clue on how to convert an int into an Integer. So, not wanting to depart on a bad foot (I guess I have some type of heart). I've decided that I'll finally ask him about his Struts experience:

Me >> "Ok, so tell me about your Struts experience."

Candidate >> "Well I've never actually worked with Struts before but I can tell you about how it works..."

After a brief conversation with a friend of mine on IM he started talking about SOA and how some proclaim it will be the end of anything not SOA. He even mentioned that Microsoft claimed that it would be the end of object orientated programing. Well I'm not sure what Microsoft claimed but here are my responses. Considering it's been a while since I blogged anything I might as well as start with something controversal. So without further delay here is my brief diatribe:

[15:16] CJ: have you heard that object-oriented design is going to be obsolete - replaced by SOA?
[15:29] Matt: Do they really claim SOA is going to replace OOP?
[15:29] CJ: microsoft does
[15:34] Matt: Everytime someone makes a statement about some big pie in the sky ground shaking achievement or advancement of technology I catagorically dismiss it as simple ego stroking, hand-waving, baloney
[15:36] Matt: SOA is going to be as popular as Web Service. And dont' get me wrong I'm not saying web service don't work I'm just saying after 2 years of listening lunatics web services is now where it belongs as a simple bridging technology. SOA is just a framework that utilizes said bridge.
[15:38] Matt: and that's about it. They'll tell you about how business will be united, and system gaps will be closed and how poor starving children in africa will be feed 3 square meals a day but at the end it's just some silly framework that's banking on a bunch of competing companies to hold hands. And it may even happen some day in the very distant future in a galexy far far way

There you have my humble opinion of SOA. Sorry for any spelling errors and whatnot. This is simply from my IM history unedited.

I just finished reading a posting titled "Pains of Legacy" that references an article on JavaLobby: "Changing Legacy Code Without Making a Mess". They both started me thinking of my own approach to code I did not write. My feelings on refactoring legacy code mimic my feelings on performance optimization. Don't do it, and don't do it yet. In fact I apply this logic to any code which did not originate with me legacy or not.

Programmers when handed a task that involves code written by people forgotten or even their fellow developers take it as a personal crusade to set things right. This often involves reformatting the code and now these days refactoring it as well. Unless you are explicitly told to do so with the project plan and schedule to back it up it is my opinion that you have make as minor a change as possible with full documentation as to why. You further have to do it using the same style as the remainder of the code otherwise the readability will drop even further when you begin mixing styles.

The reasoning for my approach are simple. If you choose the path of refactoring something completely you're throwing yourself into the fire. The code your looking at while awkward looking probably conformed to some type of programming style back in it's day. On top of that most developers aren't the most verbose in their comments or documentation. What rules or contracts they had in mind when the wrote the code have long been forgotten. And you can't count on unit tests to ack as a safety net in these circumstances. In fact your unit tests will most likely all pass and you'll fell good about yourself. But take just a moment to think about that. What are you testing? Are you testing code for which the design contract has long been forgotten or are you testing some refactored code that you now understand. I guess you could add the unit tests first, refactor and the update your unit tests. But I don't see how that is any better. I would be a good exercise in understanding what the current code base is doing a little better and help with testing if you made a minor change. Even bigger than all that is that you'll end up checking in something that's a needle in a haystack of legacy code. Considering the bigger picture your unit tests lose their meaning. While testing the evident you may have over looked little side effects and whatnot.

In conclusion refactoring legacy code, in my opinion, is unnecessary and error prone. The only time it is safe and makes sense to do it if you can refactor an entire system of an application. But that is an project onto itself.