I will be speaking on Spring MVC. The title says Spring 2.5 MVC... But I'm throwing a curve ball... it will be Spring 3.0 MVC. See you there!
Tuesday, December 23, 2008
Speaking at Code Mash 2009
I will be speaking on Spring MVC. The title says Spring 2.5 MVC... But I'm throwing a curve ball... it will be Spring 3.0 MVC. See you there!
Monday, December 22, 2008
Complexity and Architecture
It has been too long since I had a post... I have a number of scribbled notes of blog ideas, but little time. I'm in the process of starting to write the spring 3 book, which may take me off grid more than normal. I will make an effort to post a couple of times a month (more if there is something cool to document). Currently my mind has been on 3 subjects; Spring, Architecture and languages. This blog is regarding one of the often forgotten concerns of architecture... complexity.
Defining Software Architecture
I have been in a large number of conference BOFs this year. When the audience is slow in starting a conversation, the question we gravitate to is: "What is a Software Architect?" or its keen "What is Software Architecture?". I guess I shouldn't be surprised, but it is amazing how diverse the answers to these questions are. It is a reflection of at least two things... 1) the immaturity of our industry and /or 2) the lack of standardization in this space. The conversation spans from design decisions to application architecture to enterprise architecture.
Martin Fowler defines architecture as "things that people per-ceive as hard to change". This is a really responisble definition.
I like to define it as "making decisions on all the non-funcational requirements" and "managing all the things you can't control"
The area of non-functional requirements would include:
The subject that is rarely vocalized and debated in architecture is that of complexity. Neal Ford, in a couple of his talks with NFJS, talks about principles that were documented by anciet philosophers... that of essential and accidental properties. He carries this forward into software architecture in a way that we as an industry really need to talk about. That of software architecture decisions moving the enterprise forward in a way that has essential complexity or in a way that increases the accidental complexity. Neal further clarifies the point with the following comments... We have a hard problem (Essential complexity) and we have made our problem hard (Accidental complexity). Well done Neal! Very easy to envision.
Is complexity one of the non-functional requirements which your architecture team is looking at? If not, It seems likely that what is left is accidental.
What is a concrete example of this?
Let's say that your enterprise has just purchased a shiny new ESB. Suppose there wasn't a project need for it... it was just the stated SOA direction of your organization. When down from on high the edict is brought to your project that you must use the ESB in order to justify the $1M expense. Perhaps it is a fit... but perhaps you are about to fit the square peg in the round hole... in other words accidental complexity.
Where does Accidental Complexity come from?
Neal would say that it comes from vendors who are the pushers of accidental complexity... however there is something deeper here. The reason they are referred to as the pushers is that they are incented to sell you a solution. The solution may not fit your needs exactly, but hey, if they can show you a vision of how it could help, then there is a framework to following and life should be more simplified. So essentially we are saying that any choice which doesn't provide the best solution brings complexity.
We could also say that the more stuff / more solutions we have brings complexity. So by adding more frameworks and options we have added complexity. Conversely, many organizations fall into the trap of standardizing certain aspects of development... like everything is an EJB or we don't use store procedures here. In this situation what happens is that the architect and developers will have to come up with a more complex solution in order to be compliant with the corporate standards.
I'm open to suggestions and challenges... but I think we can conclude that much of our accident complexity comes from not applying the best solution to the problem. I would expect that most teams would not do this deliberately. So the team is either 1) ignorant of the best option (which can be fixed through experience and training) or 2) it is forced upon them.
I will close with the following challenges and questions:
Next time you are looking at a software component... Ask yourself the following
1) Does it simplify the problem?
2) Is there a more simplified solution?
3) Is it testable and verifiable?
4) Does it add complexity upstream or downstream of the problem?
When evaluating solutions... try to put a value on the level of complexity. Here are some ideas:
1) If it moves code or configuration into a proprietary solution then increase its complexity score.
2) If it allows you to write less code for the same functionality then decrease its complexity score.
3) If it enhances testability, decrease its complexity score.
4) How easy is it to monitor and maintain?
5) How easy is it to integrate with and is it standards compliant?
Good luck and Happy Holidays!
Defining Software Architecture
I have been in a large number of conference BOFs this year. When the audience is slow in starting a conversation, the question we gravitate to is: "What is a Software Architect?" or its keen "What is Software Architecture?". I guess I shouldn't be surprised, but it is amazing how diverse the answers to these questions are. It is a reflection of at least two things... 1) the immaturity of our industry and /or 2) the lack of standardization in this space. The conversation spans from design decisions to application architecture to enterprise architecture.
Martin Fowler defines architecture as "things that people per-ceive as hard to change". This is a really responisble definition.
I like to define it as "making decisions on all the non-funcational requirements" and "managing all the things you can't control"
The area of non-functional requirements would include:
- User Experience
- Performance / Response Time
- Scalability
- Security
- Frameworks
- Complexity
- On public web: Number of Requests
- Number of Threads / Connections
- Number of returns from a user generated search
- Items in a batch
The subject that is rarely vocalized and debated in architecture is that of complexity. Neal Ford, in a couple of his talks with NFJS, talks about principles that were documented by anciet philosophers... that of essential and accidental properties. He carries this forward into software architecture in a way that we as an industry really need to talk about. That of software architecture decisions moving the enterprise forward in a way that has essential complexity or in a way that increases the accidental complexity. Neal further clarifies the point with the following comments... We have a hard problem (Essential complexity) and we have made our problem hard (Accidental complexity). Well done Neal! Very easy to envision.
Is complexity one of the non-functional requirements which your architecture team is looking at? If not, It seems likely that what is left is accidental.
What is a concrete example of this?
Let's say that your enterprise has just purchased a shiny new ESB. Suppose there wasn't a project need for it... it was just the stated SOA direction of your organization. When down from on high the edict is brought to your project that you must use the ESB in order to justify the $1M expense. Perhaps it is a fit... but perhaps you are about to fit the square peg in the round hole... in other words accidental complexity.
Where does Accidental Complexity come from?
Neal would say that it comes from vendors who are the pushers of accidental complexity... however there is something deeper here. The reason they are referred to as the pushers is that they are incented to sell you a solution. The solution may not fit your needs exactly, but hey, if they can show you a vision of how it could help, then there is a framework to following and life should be more simplified. So essentially we are saying that any choice which doesn't provide the best solution brings complexity.
We could also say that the more stuff / more solutions we have brings complexity. So by adding more frameworks and options we have added complexity. Conversely, many organizations fall into the trap of standardizing certain aspects of development... like everything is an EJB or we don't use store procedures here. In this situation what happens is that the architect and developers will have to come up with a more complex solution in order to be compliant with the corporate standards.
I'm open to suggestions and challenges... but I think we can conclude that much of our accident complexity comes from not applying the best solution to the problem. I would expect that most teams would not do this deliberately. So the team is either 1) ignorant of the best option (which can be fixed through experience and training) or 2) it is forced upon them.
I will close with the following challenges and questions:
Next time you are looking at a software component... Ask yourself the following
1) Does it simplify the problem?
2) Is there a more simplified solution?
3) Is it testable and verifiable?
4) Does it add complexity upstream or downstream of the problem?
When evaluating solutions... try to put a value on the level of complexity. Here are some ideas:
1) If it moves code or configuration into a proprietary solution then increase its complexity score.
2) If it allows you to write less code for the same functionality then decrease its complexity score.
3) If it enhances testability, decrease its complexity score.
4) How easy is it to monitor and maintain?
5) How easy is it to integrate with and is it standards compliant?
Good luck and Happy Holidays!
Thursday, November 13, 2008
Boulder / Denver JUG Talks
It seems I can't escape Denver. I was there last month at the JUG meeting. Matthew McCullough has some commentary on his blog. It seems Matt did a presentation on iPhone development this month. I will be speaking at NFJS this weekend in Denver. My topics include:
- Java Memory Management and GC
- Hacking - The Dark Arts
- Security Code Review
- Spring / JPA
- Spring 2.5 - Spring without XML
- Architecture and Scaling
- Java Memory Management and GC
- Hacking - The Dark Arts
- Security Code Review
- Spring / JPA
- Spring 2.5 - Spring without XML
- Architecture and Scaling
Monday, October 20, 2008
Favorite Development Tools of 2008
- Mac
- TextMate - What a great tool! Reason enough to own a Mac.
- Intellij - Version 8 is looking good.
- Groovy - This is becoming my favorite tool.
- Grails
- git - It is replacing cvs and subversion.
- gradle - replacing ant and maven
- hudson - looking to see if it replaces cruise control.
- Fusion - developing C# is more fun on a Mac.
- Spring 2.5 MVC - If you can't do Grails... this is the way to do it.
- Clojure - Interesting Language... I know very little at this point.
- F# - Probably the most interesting language on the .Net platform.
- Spring 3 and what I call ADD or Annotated Driven Development :)
- I would like to see a refresh on xplanner - This would be a great candidate for Grails.
jps - The Java way when you need to kill something Groovy
As a speaker, I'm often showing "how" to do something and often requested for "When" / "Why". I just experienced a great example of this with jps. jps is of course is the Java ps tool that is included with JDK5 and 6. So it is already on a Java developer's machine. It is the platform independent way to get PIDs.
How it Started
The Yak-Shaving started when I decided to run a groovy script from TextMate. I conventiently hit+R. Everything ran the way I wanted it to. Except... There wasn't an end to the program script... idiot! So, I closed TextMate... Still Running....
Step 1
First I went to the command line and did a ps... which didn't result in much. I followed this up with a ps -ef. Way too much info... so I ended with a ps -ef | grep JavaVM. Things just got worst. That is a lot of information!
Solution
Along comes jps. A simple jps (no args) and here are the results
9382
10620 GroovyStarter
10314 JConsole
10761 Jps
There it is GroovyStarter... kill 10620.
... and what if you had multiple GroovyStarter scripts running. Well, jps -m will give you the command-line of the script, which includes the groovy script name.
How it Started
The Yak-Shaving started when I decided to run a groovy script from TextMate. I conventiently hit
Step 1
First I went to the command line and did a ps... which didn't result in much. I followed this up with a ps -ef. Way too much info... so I ended with a ps -ef | grep JavaVM. Things just got worst. That is a lot of information!
Solution
Along comes jps. A simple jps (no args) and here are the results
9382
10620 GroovyStarter
10314 JConsole
10761 Jps
There it is GroovyStarter... kill 10620.
... and what if you had multiple GroovyStarter scripts running. Well, jps -m will give you the command-line of the script, which includes the groovy script name.
Sunday, October 19, 2008
Grails JMX Plugin
I just created and released version 0.3 of the Grails JMX Plugin. The code is at github; git://github.com/kensipe/jmx-grails-plugin.git . The documentation is at grails; http://grails.org/JMX+Plugin.
Sometime this week, I'll post some tips and tricks for using the JMX Plugin with Grails.
Sometime this week, I'll post some tips and tricks for using the JMX Plugin with Grails.
Saturday, October 18, 2008
Cooking Chef vs. Polygot Programmer
Occasionally crazy analogies pop up in my head. Sometimes these ideas don't make sense to anyone but me. Let me know if I've gone off the deep end.
So I was thinking what it was like growing up when I didn't have a microwave and how useful that tool is. Then it occurred to me that as useful as it is, there are things I would never put in the microwave. Take for instance a turkey. Perhaps it is possible to cook a turkey in a microwave, but why? You can cook toast on a gas stove as well, but a toaster just seems more appropriate. When playing chef, each tool provides a specific value. Turkey in the oven, toast in the toaster, and butter melting in the microwave.
Stretching this thought into a conversation on technology, I'm reminded of a term Neal Ford is credited with: The polygot programmer.
Why is it that developers and programmers pick camps? Why does an organization limit their technology choices to one or a small handful? When an organization says they are a "Java Shop" or a ".Net Shop", what I hear is "We only use microwaves to cook here". In many of these shops they are doing with code what can be equivalent to cooking a turkey in a microwave. They can get it to work, but it doesn't taste so good!
So I was thinking what it was like growing up when I didn't have a microwave and how useful that tool is. Then it occurred to me that as useful as it is, there are things I would never put in the microwave. Take for instance a turkey. Perhaps it is possible to cook a turkey in a microwave, but why? You can cook toast on a gas stove as well, but a toaster just seems more appropriate. When playing chef, each tool provides a specific value. Turkey in the oven, toast in the toaster, and butter melting in the microwave.
Stretching this thought into a conversation on technology, I'm reminded of a term Neal Ford is credited with: The polygot programmer.
Why is it that developers and programmers pick camps? Why does an organization limit their technology choices to one or a small handful? When an organization says they are a "Java Shop" or a ".Net Shop", what I hear is "We only use microwaves to cook here". In many of these shops they are doing with code what can be equivalent to cooking a turkey in a microwave. They can get it to work, but it doesn't taste so good!
Subscribe to:
Posts (Atom)
