I was reading one of the links that I get as RSS sent from Ragawald today about JSR-308 (What hath java wrought). This JSR describes some additional annotation on types that would extend the java type system allowing the compiler to do some more static checking work for me. There was a further breakdown explanation that was linked off the "What hath java wrought" article that is also worth reading for a good background on what this JSR could translate into. The additional write up is on Wide Awake Developers titled When Should You Jump? JSR 308. That's When.
Dynamic vs. Static
SO - I took a little dive down The Rabbit Hole, as I am apt to do, and followed a bunch of links on JSR-308. To be perfectly honest I am greatly disturbed by the information that I found. There has been a great deal of discussion about Dynamic languages, static languages and languages that are mostly static taking on some of the dynamic language goodnesses (or vise versa). Both sides (static and dynamic) have some relativly cogent arguments about why their thing-a-ma-gigger should be the one that means the most to the most programmers. Personally, as I have stated in the past, I am a "use the best tool for the job" type of person. Not only that, but I tend to try to bring in the stylistic flavor of other languages into the language I am using at the time, often mixing styles and metaphores as I go. Both arguments are powerful and at the same time equally pointless in the face of just being simple and getting done what you need to get done.
So, in terms of the JSR specifically, let me say that I am disappointed because the JSR I don't think is bringing anything of intrinsic value to the java language. This may be because I am looking for inherntly simple things or it may just be that I am personally a simpleton but lets assume that I give / gave myself the benefit of the doubt in this case. The title of the JSR-308 says the following:
"JSR 308, “Annotations on Java Types”, enriches the Java annotation system"
which I will admit on the surface seems simple, but it SOOOOO very much implies so much more. This JSR would allow the common coder to add annotations on java types and even further would allow the common coder to supply an annotation to a generic type as well. Some people would consider this to be progress... I am personally not so sure. Take the following example shamlessly pilfered from the "Wide Awake Developers" site:
void marshal(@Readonly Object jaxbElement, @Mutable Writer writer) @Readonly { ... }
Can someone please explain to me what this line would mean to some other class in my code? Better yet can someone please explain what are the potential outcomes of having a line like this in my code in an effort to "improve" my overall codebase?
If I had to guess someone can probably explain to me that the @Readonly is telling me that jaxbElement will not change in the method context. They can tell me that @Mutable is telling me that the 'writer' variable will change in the method context and that the second @Readonly is telling me that the method itself can only be called by something else that is also marked as @Readonly. Holy CRAP is that an amazing amount to remember about a single method.
Now I can hear a bunch of people sputtering that this feature would eventually find its way into being managed by the IDE's we may all use and love. I personally say that even if it does, that the value introduced by these new annotations is/will be lost on most people.
K.I.S.S.
One of the first things that I learned in programming and IT in general is that one should always keep a level head and try to look for the simple explanations and simple ways of doing something first. Keep It Simple Stupid is what I was always told. I came to understand that for the most part this old adage holds true. Granted that there are times where it is not always possible to do, maybe it is a particularly hard algorithm that needs implementing or other such item - but even in those cases attempting to be as straight forward as possible will help the person that follows you up in attempting to maintain and support the code. The addition of these new type annotations I do not think is in the vein of KISS. I think that this new JSR is about attempting to solve an ever smaller set of 'potential' coding issues (bad nulls, modifying variables you didn't intend and the like). The value proposition I just don't feel is there.
Specifically I think that this JSR is heading in the wrong direction. While most newer languages these days are heading in the direction of being more dynamic, more human readable and human understandable - this annotation JSR moves java in the other direction. We all know programming is hard but do we really need to make it even more so with something like this? This JSR raises the barrier to understanding what the code is doing in my opinion, lowering the overall understanding of java programmers of how their system works. Keep in mind that we have some other already complex things to solve... things like understanding multithreading and keywords like volatile better, maybe even adding some better multicore-multithreading support into the language... instead and to my dismay we as a community are out there attempting to solve a little niche of a problem. Granted the types of problems that this can solve are plenty hard to find and debug - but for an experienced programmer they are a small amount of an overall codebase.
SOOOO... How does one interpret...
Think about the interpretation of the example line I provided. I once said programming and being intuitive was all about memory / context - the idea of being able to hold in active memory about 7 +- 2 things, if I have to hold onto MORE then 7 items just to interpret what a singular statement is attempting to do and not even a statement per se. but a method declaration - I believe that I have bastardized the language. Why work to make it so hard for someone to just "Grok" what is being done that it is not worth the time it may take to learn to use the new feature. I would venture to say that it may be so hard to use this potential new feature 'correctly' that most people will just skip it altogether, being intent on what they know and understand. It will take the avg. person so long to make good use of the new feature that the language may be long dead before someone really makes it part of the main stream of development in java.
Should people start to think about learning a new language? I am not sure if that is the message I would want to convey (the blogs I linked in the first part of this message think so). I would rather convey that there is power in numbers and power in voices - if you like me think that this is a rather SORRY direction for the language to be heading in over all... SPEAK UP and say so. Send sun messages, get involved in the JSR project and get this sort of thing derailed before it starts. Other wise, the language you are working in right now my go the way of M code, or Cobol.
Wednesday, May 14, 2008
Tuesday, May 6, 2008
Stylistic Intuition - Or not!
A fair friend of mine Raganwald wrote a post on the word "intuitive" stating that at least as it applies to programming languages it just isn't (i.e. it doesn't apply). A similar topic came up at work @ Big Co. in the last week or two in the form of something that company has not had to date... a coding style guide and a list of coder guidelines for how common tasks are performed in code at Big Co.
Perception is Reality
Intuitive means different things to different people. Something that is intuitive is really all about how the person looking at a particular item sees that item. As raganwald put it:
"And this is why it [the word intuitive] is not a very helpful word. Like good design, it means different things to different people."
it seems that this point about it meaning different things to different people is where Big Co. programmers are currently caught up. There are a number of people that have stated that the idea of having a coding 'guide' as well as a best practices guide is just a waste of time. Some have also said that the time spent on this endeavor and the time that may be spent on 'enforcing' a standard are wasted. Specifically that Big Co. programmers should be spending their time working at making things simpler or bringing about more simplicity in the code base. While I agree with the idea that Big Co. programmers and architects should be attempting to make the code simpler I disagree that setting a standard and having guidelines is wasted effort - for the "intuitive" reasons spelled out in raganwald's post. Some other things do come to mind that I think make the effort of value as well.
Memory - Value in commonality
Style guides for source code and guidelines for common programming boilerplate tasks do have value. Specifically they have the value of allowing programmers to "study" what the Big Co. code base looks like. This is important in the same way that updating sections of the code base is, its all about peeling the onion. Everyone has the ability to hold a limited number of things in their head when they are performing a task. Studies have shown that in general the number of things a person can hold in their active memory is about 7 +- 2 items. If all the code @ Big Co. follows a similar guide, I can reduce the number of interpretations I have to make between what my 'intuitive' code structure might be, or the way I may have learned it and over time train myself to expect things in a certain way no matter what type of code I look at when working @ Big Co. Once the 'learning' has occurred it is no longer one of the things I have to hold in active memory when performing a task. The learning has made code style and guidelines something that is automatic and basic ala. training someone to do a repetitive job well allowing room in active memory for other items, like classes related to what I am coding now or refactoring currently.
Programmer Ramp up
The style guides and other boilerplate guides also have value for new hires. New programmers starting at any new job almost always ask for any documentation they can get as well as for access to the source code. The first I assume to be an effort to see how "mature" the company is while garnering information. The latter I see as a way of investigating to see if the code is 'intuitive' to them. If you were to give the new programmer, both the code and the guide - they can level set their expectations ahead of time and possibly get started on things faster then that may have otherwise. The guides and guidelines can provide a needed context that a new programmer @ Big Co. might not get nor see if every new class file they open has a different look and feel. Couldn't all the programmers in the organization be faster if they knew in advance what to expect rather then letting each new source file be a style surprise? It should also be noted that there is something to be said here about not giving new hires immediate 'write/commit' access to the source tree but that is a post for a different time.
Simplicity
Style guides drive simplicity for everyone as well. If there is a common set of guides most IDE's and a good number of text editors these days will allow for configuration. It should be more then reasonable to expect that 'configs' for the commonly used tools in the organization (and even some of the one offs) are available to make the formatting easy. Even if you the singular programmer want to have a different or DO HAVE a different way that you need to look at the source code, there is a step by which you can have your environment of choice put the file back into the 'accepted' guide/standard for the organization. In many respects I consider it more lazy to NOT follow some standard then TO follow one. You could even consider it something I consider a service to my fellow programmer.
I think in the end - a weeks worth of fighting about some things I think is worth it in the end. If I save Big Co. developers 5 minutes of time overall / day it could add up to a significant amount of time saved over time. There is always a point of diminishing returns, but I don't think that this topic is one of them.
Perception is Reality
Intuitive means different things to different people. Something that is intuitive is really all about how the person looking at a particular item sees that item. As raganwald put it:
"And this is why it [the word intuitive] is not a very helpful word. Like good design, it means different things to different people."
it seems that this point about it meaning different things to different people is where Big Co. programmers are currently caught up. There are a number of people that have stated that the idea of having a coding 'guide' as well as a best practices guide is just a waste of time. Some have also said that the time spent on this endeavor and the time that may be spent on 'enforcing' a standard are wasted. Specifically that Big Co. programmers should be spending their time working at making things simpler or bringing about more simplicity in the code base. While I agree with the idea that Big Co. programmers and architects should be attempting to make the code simpler I disagree that setting a standard and having guidelines is wasted effort - for the "intuitive" reasons spelled out in raganwald's post. Some other things do come to mind that I think make the effort of value as well.
Memory - Value in commonality
Style guides for source code and guidelines for common programming boilerplate tasks do have value. Specifically they have the value of allowing programmers to "study" what the Big Co. code base looks like. This is important in the same way that updating sections of the code base is, its all about peeling the onion. Everyone has the ability to hold a limited number of things in their head when they are performing a task. Studies have shown that in general the number of things a person can hold in their active memory is about 7 +- 2 items. If all the code @ Big Co. follows a similar guide, I can reduce the number of interpretations I have to make between what my 'intuitive' code structure might be, or the way I may have learned it and over time train myself to expect things in a certain way no matter what type of code I look at when working @ Big Co. Once the 'learning' has occurred it is no longer one of the things I have to hold in active memory when performing a task. The learning has made code style and guidelines something that is automatic and basic ala. training someone to do a repetitive job well allowing room in active memory for other items, like classes related to what I am coding now or refactoring currently.
Programmer Ramp up
The style guides and other boilerplate guides also have value for new hires. New programmers starting at any new job almost always ask for any documentation they can get as well as for access to the source code. The first I assume to be an effort to see how "mature" the company is while garnering information. The latter I see as a way of investigating to see if the code is 'intuitive' to them. If you were to give the new programmer, both the code and the guide - they can level set their expectations ahead of time and possibly get started on things faster then that may have otherwise. The guides and guidelines can provide a needed context that a new programmer @ Big Co. might not get nor see if every new class file they open has a different look and feel. Couldn't all the programmers in the organization be faster if they knew in advance what to expect rather then letting each new source file be a style surprise? It should also be noted that there is something to be said here about not giving new hires immediate 'write/commit' access to the source tree but that is a post for a different time.
Simplicity
Style guides drive simplicity for everyone as well. If there is a common set of guides most IDE's and a good number of text editors these days will allow for configuration. It should be more then reasonable to expect that 'configs' for the commonly used tools in the organization (and even some of the one offs) are available to make the formatting easy. Even if you the singular programmer want to have a different or DO HAVE a different way that you need to look at the source code, there is a step by which you can have your environment of choice put the file back into the 'accepted' guide/standard for the organization. In many respects I consider it more lazy to NOT follow some standard then TO follow one. You could even consider it something I consider a service to my fellow programmer.
I think in the end - a weeks worth of fighting about some things I think is worth it in the end. If I save Big Co. developers 5 minutes of time overall / day it could add up to a significant amount of time saved over time. There is always a point of diminishing returns, but I don't think that this topic is one of them.
Thursday, May 1, 2008
The Rabbit Hole
I found my self in an interesting conversation just the other day about the commonly and oft wrongly used term for a position in Big Co. called the 'Architect' or 'Software Architect' or 'System Architect', you pick your poison. These days the term 'architect' is over assigned, over used, and overloaded to mean someone that has been in the programming or software development industries for an extended period of time. 'Architect' is being used to indicate that the individuals time 'IN' should equate to them knowing what they are doing and as such that they should be able to 'architect' a good system, or at best design a bit of software now and again from scratch. In the end, this over use and overloading of the word leads to misunderstandings and misinterpretations, and I ran into one in the form of an interesting debate question:
Should an architect also be a coder?
At first I was quick to answer this question in a simple and unequivocal manner: YES!
Then I stopped and thought about the reason for asking the question in the first place and the premise for thinking that an 'architect' should not be involved in any code base, or involved in producing any code for a given system. I then provided what I thought to be a more complete argument then simply answering yes. It went something like:
How can an organization, or any given programmer, expect to have a person or persons be responsible for helping set an over all direction for a system(s) without knowing what it is made of? As a programmer I find out what a given bit of software is made of by digging in and checking out how it is coded. I look to see what the codebase would be capable of doing, what it is resilient against, what code smells might it have - what the over all feel of the code is. I can think of no better way to help set direction and I find it difficult to see the other side which states the 'architects' like managers should not be interested nor involved in how the code is written. That they should only be interested in the high level direction - and that should be their only responsibility. I turned the counter argument in my head into something that I don't like architecture groups to do - and that is to become Ivory towers, or worse yet 'Picture-tecture" groups.
I firmly believe that architects should be involved in code... they should have coding tasks in each and every scrum/sprint/dev cycle (Insert term of choice for your company here). Only in this way can they truly understand the issues and problems and come up with creative and innovative ways to solve them. You might be able to find a unique individual out there who can just "KNOW" a system by hearing it be described - but to me that sounds more like a miracle person then someone I would care to get to know OR take any direction from.
In alot of ways I would hope that an architect would be 'OK' eating their own dog food now and again and being involved in implementing some of the things that they may have at one time put down on paper for someone in a meeting or design session. In essence I think all architects should be ok chasing items down the rabbit hole now and again. Its good for the soul, its good for development and its a spectacular sign that you have someone that is REALLY interested in understanding what they are talking about. An architect interested in a full understanding is what I want - not someone who just thinks they are the shiznit, or like Joel recently posted is an 'Architect Astronaut' or even better someone who is 100% enamored with the title of a blog post. I want to be someone who does really work and ACTUALLY helps programmers solve real problems that let them be faster, and get more done with less effort. I want to chase items down the rabbit hole once and a while - stay sharp and keep current.
Should an architect also be a coder?
At first I was quick to answer this question in a simple and unequivocal manner: YES!
Then I stopped and thought about the reason for asking the question in the first place and the premise for thinking that an 'architect' should not be involved in any code base, or involved in producing any code for a given system. I then provided what I thought to be a more complete argument then simply answering yes. It went something like:
How can an organization, or any given programmer, expect to have a person or persons be responsible for helping set an over all direction for a system(s) without knowing what it is made of? As a programmer I find out what a given bit of software is made of by digging in and checking out how it is coded. I look to see what the codebase would be capable of doing, what it is resilient against, what code smells might it have - what the over all feel of the code is. I can think of no better way to help set direction and I find it difficult to see the other side which states the 'architects' like managers should not be interested nor involved in how the code is written. That they should only be interested in the high level direction - and that should be their only responsibility. I turned the counter argument in my head into something that I don't like architecture groups to do - and that is to become Ivory towers, or worse yet 'Picture-tecture" groups.
I firmly believe that architects should be involved in code... they should have coding tasks in each and every scrum/sprint/dev cycle (Insert term of choice for your company here). Only in this way can they truly understand the issues and problems and come up with creative and innovative ways to solve them. You might be able to find a unique individual out there who can just "KNOW" a system by hearing it be described - but to me that sounds more like a miracle person then someone I would care to get to know OR take any direction from.
In alot of ways I would hope that an architect would be 'OK' eating their own dog food now and again and being involved in implementing some of the things that they may have at one time put down on paper for someone in a meeting or design session. In essence I think all architects should be ok chasing items down the rabbit hole now and again. Its good for the soul, its good for development and its a spectacular sign that you have someone that is REALLY interested in understanding what they are talking about. An architect interested in a full understanding is what I want - not someone who just thinks they are the shiznit, or like Joel recently posted is an 'Architect Astronaut' or even better someone who is 100% enamored with the title of a blog post. I want to be someone who does really work and ACTUALLY helps programmers solve real problems that let them be faster, and get more done with less effort. I want to chase items down the rabbit hole once and a while - stay sharp and keep current.
Subscribe to:
Posts (Atom)
