What’s the significance of Nov 18th 1883 to software development in the US?

On November 18th 1883, the US adopted standardized time zones across the US. From a software development point of view, this means there is an interesting shift in the time zone offsets at this point in time – for example, after this date, Pacific Time is GMT-8, whereas before this date, Pacific time was GMT-7:52:58 (approx).

This becomes more interesting when dealing with Date apis that respect this date or not. For example, JodaTime does, but java.util.Date does not. When persisting dates to a database table via JDBC, JDBC does not know about the JodaTime types, it only knows about Types.DATE and Types.TIMESTAMP. Therefore this is there it starts to get wierd.

If you go DateTime -> Date -> Table, and then Table -> Date -> DateTime – you’re all good.

If you directly populate dates in the tables e.g. from scripts of other systems prior to 1883 though, JodaTime puts it’s offset on these dates when you retrieve them back out and you end up with dates and times that are off by 7mins 2 secs (approx).

An interesting issue that’s worth knowing about if you’re dealing with dates in the past.

Duct Tape Programmers & Smart Developers

I love Joel Spolsky, he just says it as it is. His comments here about Duct Tape programmers are spot on.

You need developers like this on any project – see the issues, find solutions, fix issues, get stuff done. And simply, in a way everyone else can understand. I love the comment about some technical approaches being easy to understand if you are Spock. That puts a lot of things in perspective. Being smart just for the sake of being smart does not get things done, does not help your fellow developers on the team, and usually does not help everyone get the job done and the product out of the door. What a lot of smart developers fail to realize is that there is a need to aim the level of complexity on any project to the level of the least common denominator. Think about it. If you are busy architecting and dictating ‘the way forward’ using terms and technologies that only a small number of developers on your project can understand, how does that help move the project forward to meet it’s end goal? It doesn’t. What smart developers need to realize is that being smart in order to help a project reach it’s end goal means they have to use their smartness to find the easiest, most appropriate solution that every developer can understand. Unless you can find this common ground you are not going to leverage your whole team. Think about it. If you have a team of 50 developers and you are proposing an architectural solution that only 5 developers understand and can use, this is pointless. This is not an appropriate solutions, regardless of how smart or proud you are of thinking of the idea.

It takes some smart developers a while to come to this realization, and some never get it at all. The ones that do become very valuable resources on projects because they help the team as a whole get things done. The ones that don’t get it, well, they’re destined to become astronaut architects and live in the clouds.

Maintainability: if you can only just understand what you developed, no-one else will be able to

Among Software Developers there is a distinct range of abilities and level of understanding that ranges from ‘ability to solve business problems’ and then on the other extreme is ‘ability to write compilers’. I’m not saying that if you are capable of writing compilers you cannot solve business problems, because if you work for a tools company that makes it’s money from developing compilers, you’re most likely in the right place.

The issue is, on the majority of software development projects, either in-house development or consulting engagements, you don’t often (if at all) find yourself solving anything technically that has the complexity of developing compilers. This is where the issue is with different developers on this ability/skill scale. For a developer who is entirely focused on solving business problems, and on a consulting project that is the reason you are there, this type of developer will have a hard time understanding why The Compiler Developer is inventing all kinds of wild and wacky technical solutions to problems involving every possible API and open source project they can find. The Compiler Developer on the otherhand has trouble understanding why The Business Problem Solver has no interest in investing time and budget in incorporating all these technical gizmos and doo-dads into the system that from The Business Problem Solver’s point of view just increase the risk to the project.

In reality I believe a project needs to have a good mix of ability to solve business problems and ability to use technology to best solve these problems, and it’s up to the management of the project to keep this balance healthy. If you swing the mix too rich in either direction I think you’ll have a hard time getting anything complete.

One of my most favorite quotes sums up the issues that can be created by leaving Compiler Developers to their own devices:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're
as clever as you can be when you write it, how will you ever debug it?"

 

– Brian Kernighan, the ‘K’ in ‘K&R’ (Kernighan and Ritchie), co-developer of the C programming language, from http://en.wikiquote.org/wiki/Brian_Kernighan

Kernighan makes a great point, if you have developed something that is so complicated that you have no hope of debugging it, how will anyone else be able to understand it? This is why, unfortunately from the point of view to the Compiler Developers, you need to develop code close to the lowest common denominator of technical abilities on any project, otherwise you are potentially creating a maintenance nightmare for yourself or your client with code so complex that no-one is able to understand, maintain, or fix.

Linking to other actions from a view page

Use the <g:link> tag to link to another action. For example:

To link to ‘someAction’ in the same controller being used to handle this current view page, passing an id:

<code>&lt;g:link action="someAction" id="${exampleDomainObject.id}"&gt;</code>

If the action is in a different controller, then specify the controller as well:

<code>&lt;g:link action="someAction" controller="OtherControlller" id="${exampleDomainObject.id}"&gt;</code>