I am a big fan of using Ant to do routine tasks. I just spent a bit of time figuring out how to get Hibernate 3/Ant to generate the database scripts when using annotations. The Hibernate 2 way with the SchemaExportTask doesn’t appear to work. Hopefully my notes below will save you a bit of time if you are trying to do the same.

The Hibernate 2 with hbm.xml file way:

<taskdef name=”schemaexport”
classname=”net.sf.hibernate.tool.hbm2ddl.SchemaExportTask”
classpathref=”project.class.path” />

<schemaexport
properties=”${resources.db}/database.properties”
quiet=”no”
text=”no”
drop=”yes”
delimiter=”;”
output=”${resources.db}/drop-tables.sql”>
<fileset dir=”${hibernatedoclet.dir}” includes=”**/*.hbm.xml”/>
</schemaexport>

The Hibernate 3 with Annotations way:
- Note you need to download the hibernate-tools.jar

<taskdef name=”hibernatetool”
classname=”org.hibernate.tool.ant.HibernateToolTask”
classpathref=”hibernate.export.classpath” />

<hibernatetool destdir=”${build.db.dir}”>
<annotationconfiguration configurationfile=”hibernate.cfg.xml”/>
<hbm2ddl export=”false”
create=”true”
delimiter=”;”
format=”true”
outputfilename=”create-tables.sql”/>
</hibernatetool>

I have been found of calling Agile, “only a vocabulary” for quite sometime. As most of my colleagues on the projects I have work on for the last couple of years seem to use an impressive blend of Agile terms, but somehow we never seem to be doing actual Agile development. I know there is a lot of nuance out there between the different Agile methodologies. I am not trying to get caught in that trap. I am taking the simplest broadest definition of Agile I have. Which to me basically comes down to, feature based iterative development, where new working-fully-tested (shippable) code is ready for release at the each iteration.

 

Yet, I continue to work on countless iterations that don’t even cycle through QA. Or the funniest case to me, ‘sprints’, that are dedicated to requirements gathering for the whole development team. As far as I am concerned, if you are not producing releasable code every single iteration, then you aren’t doing Agile development. I have no idea how that fits with my other post on Agile this week, but I will say that I am addressing two different extremes of the problem. In this case, I am talking about teams with no barriers to doing actual Agile development, but for some reason cannot seem to understand what Agile actually looks like.

 

I realize in one way it doesn’t matter, but for some reason I just take issue with our tendency to adapt our current habits to new vocabulary to allow us to keep making the same old mistakes…

Well, I haven’t had much time to play with my new favorite technology lately (Adobe Flex). So, I figured I would blog about one of the other software topics that peaks my curiosity.

 

For a few weeks, I have been thinking through a simple but odd idea, as it would seem to be an oxymoron, “Agile without the implementation.” Those of you that embrace Agile methodologies will immediately want to smack me down, as that statement would seem to be a complete contradiction.

 

There is however, no matter how much the Agile advocates want to argue the point, a mismatch between Agile and a number of the environments that software is developed within. The most obvious example being the government, as all Agile methodologies are based in an anti-bureaucracy mentality, and our government agencies are anything but.

 

In the last couple of months, the great state of Colorado, which I call home, started clamping down on state agency software projects. Our new governor, Bill Ritter, issued an executive order that all software projects over $10,000 are subject to oversight and management from a single state office (http://www.rockymountainnews.com/drmn/local/article/0,1299,DRMN_15_5641110,00.html). Experienced software engineers immediately understand this will only exacerbate the difficulty of building quality software, rather than help to minimize the failures that different technical groups within our state government have experienced.

 

This is obviously (or maybe ‘hopefully’) the extreme of government bureaucracy, but even within the most relaxed government agencies there is typically the requirement to do a big-up-front analysis/design to even get funding. As we all know, a main tenant of virtually all Agile methodologies is the aim to eliminate this very practice, as it almost always leads right into a waterfall like implementation methodology.

 

So, how are government software managers to succeed in circumstances that are clearly not conducive to building great software? As crazy as it sounds, I think the answer is ‘Agile without the implementation.’ The concept is based on being able to validate and execute requirements, without implementing them. Thus, a team is still able to produce tangible artifacts that are validated, while not getting stuck with the time or cost of implementation details.

 

Most must be asking, “How would one truly validate and execute requirements?” The company I work for has developed a product for executing UML 2.0 models, the Gorilla Execution Engine (GXE). This allows a small team of developers/analysts to create a true code ready specification, which has been validated by the end user through a functional user interface generated from the UML.

 

Here is how I would see the process of Agile without the implementation working. To be true to the concept of Agile, features would still be digested in small chunks iteratively. Stakeholders and users would still get a functioning user interface through each iteration that allows them to validate that the requirements have been captured correctly. The ‘domain model’ that is being executed acts as a code ready specification that would be implemented down the road in separate implementation iterations.

 

This would bring a number of benefits to government agencies. First off, they would be able to reap real benefits from the up-front requirements time that they are typically required to provide, as they would have validated requirements. Second, it allows them to still borrow from proven Agile techniques while still satisfying the bureaucratic requirements. Third, it would allow governments groups to more accurately estimate the cost of implementing the system, as they would be working from validated requirements.

 

As I work through this idea on paper, it seems fairly obvious that developing software like this could help to close the gap that governments have between there innate bureaucracy and Agile methodologies. Taking it a step further, I am starting to really embrace one of my company’s core philosophies behind the GXE, which basically says we should avoid implementation details when trying to digest requirements. Tools like the GXE give us the abstraction to be able to do this. At first I question this as incompatible with Agile, but the reality is that when done as part of feature based iterations, then it can only serve to enhance an Agile project.

 

To take one more leap from this thought process, this idea is really just a stop gap. With all the work currently being done in the declarative programming space, soon modeling will just become the core implementation. Thus, making this whole idea a moot point anyway as the requirements and implementation will simply be a model.