I’m probably the worst person to work with. I come to work, my hair un-combed, my pants often times are wrinkled, my concern for my appearance virtually non-existent. (Although I do make sure I dont emit any body odors.) That’s not why I’m hard to work with. What makes it difficult to interact with me is the fact that I don’t listen. I get locked into one vision and convincing me to see differently is almost always a challenge. I have improved as I generally try to be aware of my stubborness but many times I’m just plain bull headed. Today was one of those days. I got into a a discussion with two fellow developers and things got a little out of hand.
First an update
I’ve been hard at work with another more business knowledgeable developer implementing our application’s pricing logic. In the course of our working together I’ve taken us down the T.D.D. extreme course. I’m really trying to teach and practice the T.D.D. concept 100% on this mini project. You see, she (my working partner) has never even heard of test driven development before so when I told her we would use intentional programming she was completely baffled. Over time I ended up writing little bits end explaining bigger bits. Type, explain, explain, type and more explain went our cycle. After a while we moved from my workstation to hers where I did mostly explaining and letting her do all of the coding. (It is difficult to explain what to do without coding it myself but more beneficial for the both of us when she does the coding.) It’s been an adventure with many challenges but we’ve made some good progress. We currently have a good sized piece of our pricing logic running completely without the database and we’ve also demonstrated that we can attach pieces of it to our database and do something intelligent.
That’s where today’s drama began. We were working on attaching another significant piece of our logic to a sample of our production database when we ran into a problem with dates. Our application has a strange way of dealing with dates where it tries to completely hide the fact that we’re dealing with date values from the database. Every piece of code in our app has to work around the strange idea and do complicated date manipulation logic when reading and writing date fields. I decided that we should do something about it for our particular set of objects, something that would no longer mean a work around. I asked our resident date logic expert, another developer we’ll call Mr. Date, what to do. Our discussion went off on a tangent (as do most topics between devoted developers) then the lead developer came over and joined in. I became adamant about my big idea while the other two developers (Mr. Date and the lead guy) insisted on their agreed vision.
I believe our project, which is riddled with circular dependencies and untestable code be completely refactored incrementally by recoding little bits of business logic in an outside module. The code would be developed “test first” green bars would color the screen, Maven would jar everything up and we would bring the jarred artifact back into our main project as if it were a third party library.the business logic would depend on supporting data access objects (DAOs) which we would also code outside our main project. The main goal being to break apart our original project into a bunch of separate more focused sub modules that could be re-assembled into the original or reassembled into many other diffferent kinds of configurations giving us more flexibility. I feel the goal is only attainable if we no longer add code to the base project, rather refactor in small chunks bringing the old code and algortihms into the newer modules and most importantly refrain from creating dependencies from the newer modules on the original project. In my view any code attached to the original project is useless due to the fact that the original is riddled with senseless dependencies and tons of code we want to do away with. I say useless because the only possible way to use any code in the original project is through using our complicated build system deploying complicated config files to an overly complicated appserver and deciphering/debugging complicated exceptions that are thrown on practically every deployment. (There are some “known exceptions” where we’ll say “Oh, that’s due to component ‘X’ and should not affect behaviour except under condition ‘Y'”) Clearly this is no geniuwine use of code and good code should have much more practical uses.
The other developers feel as though we can use code from the original project. They agree with my idea up to the point of where data access code cshould go. To them data access is so specific to our DB schema that it doesn’t matter where it goes. There’s also some notion that we’ll one day get to change the database because it represents a huge problem for development. They feel that the data access code is useless code and that effort should not be spent developing it. Then there’s a strong disagreement about the destiny of our build system which I believe is inherently flawed. The lead developer thinks that we can go foward with our build system or refactor it into some useable form.
That’s the core of our differing opinions. I think it boils down to the definition of code usage. I see value in the business logic and concepts locked in our project. I also see value in the DB schema, no matter how ugly or complicated, as a means of completing any business component. I see no usage in the code in our project because it involves the complication of the build system, deployment, EJB, and appserver specifics. In my view all of it needs to be slowly rewritten into smaller managable pieces that can be used completely outside the project. These are pieces that can stand alone. The opinion of the others appears to be such that writing code that can call code in our project is code usage. They appear to care little about the importance of having completely stand-alone business objects. The complications of the build system do not seem to affect the others as it does me. (By the way, I’m the one who wrote the build system.) Overall I deeply respect and appreciate their opinions but this was one of those discussions where I felt I completely misunderstood where they were coming from. I am hell bent on how I percieve our project mostly because of supporting facts. The only way I would see things differently is if I was somehow wrong about that perception. It is disturbing that the rest of the team doesn’t see the problem as I see it. Or maybe they do but they somehow don’t feel as urgent a need to correct all of the major flaws as I do. I don’t have much more to say on the topic. Holla if you feel my pain…