Archive for category Opinion
My CSM (Certified ScrumMaster) trainer is probably going to kill me after reading this title, as one of the things she kept repeating during the CSM course was that you don’t sell Scrum, and as such, pricing strategies . You sell a product to a client, and Scrum is a means to an end to get that product to that client in the most efficient way possible for all parties involved. Scrum focuses on content, early delivery and providing as much value as fast as possible. It also factors in the certainty of change. Read the rest of this entry »
As a Java consultant, I come in contact with IBM products quite often. More often than I would personally hope. I’m not saying that IBM makes bad products, they have their merits, but more often than not the choice for IBM products is more out of corporate compliance than it is because of the technical needs of the projects than are built on top of the projects.
Currently, I’m working on a project that uses a whole lot of the IBM stack: the DB2 AS/400 database, IBM Websphere 6.1 and 7, IBM Process Server, IBM Portal Server on top of a Websphere 6.1 installation, all developed on either RAD (front-end and back-end) or WID (the processes). It shouldn’t come as a surprise that setting up the development workspace is a couple of days worth of work. And then you can only hope you haven’t forgotten to apply the patches and that the integration between all those products has gone flawlessly. Off course, this kind of setup also means that you need one hell of a development machine when you want to develop through the entire chain of the application. 2 Gb of memory is not an option here, folks.
This got me thinking, since the last project I was on was also mainly IBM based. Is the choice for IBM projects a valid one from a technical point of view, or are there cheaper, more developer-friendly and above all, technically rivalling products out there in the open source world, whilst still keeping up an enterprise-like reputation? Read the rest of this entry »
Web clients are hot. Hip. Sometimes even hype. But having worked on different projects, both fat clients and web applications, I’m starting to grow a consciousness on when a web application is appropriate and when the choice for a fat client would be a more sane one.
Fat clients have a bad reputation. Deployment issues being the main culprit here. With web applications, you just deploy it on a server and every user has instant access to the application. Fat clients, for example using Java Webstart, need to be installed on the local client. They also require a JVM. Updating is not instantly, but requires a restart in most cases (unless for example you’re using some fancy modular architecture that allows updating on the fly). From an operations standpoint, fat clients are maintenance burden that isn’t popular. But Java Webstart has evolved, and in the light of that evolution, perhaps it is time to re-evaluate our behavior on defaulting to a web client. Read the rest of this entry »
Devoxx, the yearly appointment for Java geeks is upon us again. And off course I’m attending. As I have for the last 4 years or so. Being from Belgium and a Java programmer, it’s a practical no-brainer. For those not familiar with Devoxx, it used to be called Javapolis (but due to some dark political games, they changed names). It’s mainly split up w 2 parts: a two day University, featuring 3 hour in-depth talks and a three day Conference, with 1 hour talks which are more practice driven.
The first day of the university I chose two talks. The first one was called ‘The Productive Programmer’ and was about how to improve productivity as a developer (and a plug towards the book off course). A lot of obvious stuff in there, but always nice to hear the things I need to be productive are in there. It all revolves around ‘flow’. Being able to sustain a level of concentration in which you can do tremendous amounts of work. Like an interruption-free period of day. Like dual monitors on which you can display all the information you need. Like not having to use the mouse. Somehow I expected a plea towards Vim. Rates slightly under Uncle Bob’s talk last year about craftsmanship and ethics (and that says a lot).
In the afternoon I went to see the Spring Roo talk. I tried Roo in the past and wasn’t that impressed. This demo showed me some opportunities in which I see Roo flourish. Not in enterprise application development. It’s a wee bit to young for that and I don’t think that the mainstream development world is ready for the likes of Roo and it’s ITD’s (try and explain that to a 20-year Cobol-converted-to-Java developer, or worse, the army of offshore Indian developers). I do see a really big potential in prototyping. Being able to reverse engineer any database schema into a bunch of JPA entities and then build a complete (although somewhat basic) web GUI around it, seems really nice when you quickly want to show a client something that works. If you want to expose the database through a REST interface, this is done in a matter of minutes. As I said, the web UI is fairly simple (it does have complete CRUD capabilities with pluggable security, i18n, …) and won’t suffice for about 99.9% of your clients. But it’s a nice feature to be able to talk to a client, connect to its arcane database and whip up a RESTful web UI in minutes.
So far for day one…
When I started Java development, I got to know the unpleasant nature of CVS. Sure it was better than Visual SourceSafe (by a really small margin), but still, it was a real pain in the butt. Then I witnessed the migration to Subversion. The skies cleared and the sun was shining again. Finally a decent SCM with all the capabilities one would ever hope. Sure, merging from branches still had the capability of making you bald in a single pull, but anything was better than CVS.
Recently, I switched to Git. While the switch from CVS to Subversion was quite straightforward, the move to Git was less so. Git is a paradigm shift and a completely different ballgame. With Git, there is no ‘server’. There are just clones of repositories everywhere. Off course, one of those clones can function as a master repository, filling the role of a ‘server’, a scenario used almost every time. Everyone works on their own clone and commit to their own repository. When they want to, they can push their changes to the master (if they have the rights to do so). You can also turn it around: the master can pull changes from the clones into its repository. And you have another possibility: you can pull changes from someone else’s repository. This is the nature of the beast called ‘Distributed SCM’. It’s SkyNet, there is no system core.
Git was popular in Linux kernel development. Everyone had their own kernel code and tinker at will. If the changes were any good, someone else could pull them in and take a look. If they were great, the master could pull them in, or someone who is able to push to the master pulls them in, takes a look and pushes them to the master. It’s an OSS wet dream.
Now, a lot of big Java companies are jumping on the Git bandwagon. SpringSource has migrated all of its codebase to their own Git repository and very recently JBoss moved Hibernate to GitHub. And why wouldn’t they? Git is superior to Subversion in every way. It takes a bit of getting used to, but then again, the same could be said of other SCM tools.
All of this leads me to believe that Subversion is dying slowly, as is the case with most software for which there is a better open-source product with a small learning and adoption curve. Subversion, you’ve been a real help, sorry to see you go, but it’s time to head to the attic. Git’s moving in.
Goodbye, old friend.
Having done a fair amount of projects myself, I’m starting to get a picture of what it takes to be productive. Mostly it’s just one or two small things, but together they really make a difference. Most of them have to do with sustaining a constant flow of thought. Let me point out a few:
A programmer needs space to work on. I cannot emphasize this enough. A monitor is a very small investment and studies show that developers that have two or more monitors are a lot more productive than those stuck with one. Alt-tab isn’t just annoying when having to do it 50+ times a day, it disturbs a developer in his “flow”.
More than often companies give the same hardware to the IT department as to their other departments. This is plain wrong. There’s nothing, I repeat nothing, as annoying as a hung computer whilst developing or debugging: it disturbs the flow of thought. 2 Gb of RAM may be enough for administrative personnel using Word and Outlook, but don’t even think for a minute it’ll be enough for a developer having an IDE, an application server, a database and perhaps a virtual machine running at the same time.
Free soft drinks and/or coffee
Small investment, huge appreciation. Nothing more, nothing less.
Unrestricted internet access
Picture this: you stumbled upon an issue. After looking through the PDF reference on your hard drive to no avail, you decide to try your luck on Google. On of the search results seems interesting, but the site has been blocked. Sounds familiar? Look, I’m all for banning Facebook at work, but please, don’t block all the blogging sites. It’s ricidulous for a developer to stumble upon the solution, only to be greeted by Websense with the message ‘Blocked: Information Technology’. So, ban Facebook and online gaming sites but leave the rest open. That being said, Websense is a real PITA.
Allow for IM
Communication is key to the success of a team. So why do companies keep insisting on blocking IM? If you don’t want your employees to chat with friends, provide an internal IM server (like OpenFire). No IM capabilities for a development team is not an option, unless you want your development team running around all the time!
One of those products that has a huge ROI. No restarts, less developer frustration for the cost of hiring a consultant for 2 hours.
Provide VM’s for environments
If your deployment environment takes more than 5 minutes to set up, provide a virtual machine that has a working, fully-configured environment that is ready to use and kept up to date regularly. If you need a wiki to explain an environment setup for local deployments, provide a VM instead, either locally or on a VM server (one per developer).
If you have other quick gains, feel free to comment.
Recently, I tried JRebel again. I say again, as I’ve tried it before, with varying success (mostly because of the way the applications I write behave, which isn’t JRebel’s fault). But my recent attempt was more than successful.
For most of my projects, I use IntelliJ and Maven. They’re a match made in heaven and really speed up my development turnaround. But still, every time I change some of the logic in my services, I’m forced to restart or republish my application (I mostly write desktop applications). Not good. So here comes JRebel to the rescue.
JRebel is a replacement for the Hotswap capabilities of the standard Oracle JVM. As you may know, Hotswap only supports certain changes to the code, such as changes to the body of a method. Things like adding a private method, adding a field or changing an interface are not supported.
JRebel is configured as a JVM agent and extends the JVM classloader to handle on-the-fly reloading of classes and resources. Yep, you read it correctly, also resources. JRebel supports among others Spring, which results in the neat fact that when you change your Spring context XML, changes are done immediately. No restart required. If your Spring context uses a bean of a class that is changed, JRebel detects this and will reinstantiate that bean and re-inject it.
When using Maven, integrating JRebel is a piece of cake. JRebel has a Maven plugin that nicely generates the rebel.xml configuration file, which JRebel uses to determine which resources and classfiles it needs to monitor for changes. No manual editing needed.
The same goes for IntelliJ, which provides a plugin. When it sees a rebel.xml file in the classpath, it automatically adds a JRebel facet to your project. The plugin adds 2 additional run buttons for running the application with the JRebel agent.
Needless to say, this tool is one for my toolbox. Oh yeah, JRebel is free for opensource projects!
If you want to comment on my articles, please do so. However, all comments need to be approved by me, so please adhere to the following rules:
- Use a valid email address
- No profanity or name calling (“YOU SUCK!!!” falls under that category)
- No spamming
If you follow these rules, I’ll approve even the most disagreeing comments (please read this if you want to disagree in style: DH levels).
MySQL is a dead product walking. I know it, people around me are starting to realize it and Monty sure as hell knows it. For those not familiar with MySQL’s roots, Monty Widenius is one of the founder of MySQL.
Recently, Monty has staged an all-out attack on the Sun-Oracle merger, due to the promises that Oracle made towards the MySQL product that apparently it has no intention to keep.
Luckily, we (MySQL users) have a great alternative: MariaDB. MariaDB is a fully compatible MySQL fork, once again backed by Monty. And it has all the features MySQL has and then some. Better multicore support, better performance, more storage engines, … If you’re planning on using MySQL for any project, consider using MariaDB instead. For the Ubuntu users out there, there are APT repositories available for MariaDB, and they are updated frequently.
Now if only Monty was able to rebuild the client libraries for MySQL to remove that pesky GPL license…
When you think of it, a large software company can easily be compared to an army. Let’s see if we can cover the ranks.
This one is easy. These are the mainstream software developers. Like soldiers, some have specialities, other are just plain cannon fodder. As in the army, they can move up the ladder.
These are your senior developers. They have experience, or have had more schooling which enables them to enter the company higher on the ladder. They should be able to cope with responsibility and make decisions that affect the performance of those they manage.
Like any organisational structure, the higher one goes up the ladder, the fewer in numbers. These senior officers are the management within the company. You’ll find majors (unit managers), colonels (divisions manangers) up to generals (CEO’s) and any rank in between. These are the guys that should be able to make the hard decisions. It’s impossible to enter the army with these ranks without experience, just like a company. You won’t start your career as a CEO (unless you start your own small firm, but then this article doesn’t really apply anymore).
In the army, intelligence can mean the difference between success and failure. In software companies, intelligence can be seen as the analysts. They build the blueprints that ultimately will decide if a project will succeed or not. As with intelligence, most of the work is done up front. Once the operation (project) begins, their main objective is to provide steering and updates to the situation at hand.
In the army, the engineers pave the way and provide logistical support to the army. In a software company, these are your system administrators. They make sure the hardware keeps running and provide logistical support where and if needed.
I think that covers about all the positions within a company. However, software companies are lacking something crucial. The US Army has the 75th Ranger Regiment, the US Navy has the SEALs. We need something like that.
Rangers and SEALs are the elite. They are deployed when all other options have been depleted and the situation demands for a quick and professional intervention. When they go in, they get the job done.
In my opinion, every large software company needs one of more elite teams, depending on the size. The decision to deploy these elites should not be taken lightly: it’s expensive. As it should be. These are experts in their field and are a force to be reckoned with. When they make a decision, there shouldn’t be any second guessing (client or company). You’ll be giving these guys carte blache to reach the objective. In other words: you shouldn’t use these guys for putting out a small brushfire. No, you deploy these guys when the whole forest is on fire. You’ll be counting on them to put the fire out, utilising all and any resources they have (including all of the above ranks). Like the army elites, you won’t be using these guys when there’s no crisis. Like, say, transferring them to an active unit because otherwise they’re just costing the company money (that said, given a large enough software company, they’ll be occupied just about always). No. You make these guys train. Hard. You make sure they keep being the best of the best. You do regular checks to weed out those who shouldn’t be in the elite corps anymore and make it very clear among the members of that team that they shouldn’t take their place for granted. Even worse, you make dismissal a very public affair within the company. You make sure they are instantly deployable, anytime, anywhere. When the job is under control, you bring them back and let the main army handle the rest. You don’t keep these guys around for the fun of it. At most, you’ll leave a couple of elites behind a bit longer so they can make sure a second intervention won’t needed.
The client also be aware of the capabilities of such a unit. It’s very tempting for a client to always demand the use of such a unit once he knows it exists. After all, all the clients want the best team to get the job done. However, and this should be made very clear, the use of the elites should be at the discretion of the company, not the client. Their job is to defuse a situaton.
Why don’t companies do this? It costs a lot of money and most think they don’t need such a team since all their developers are elites. I would say ‘keep dreaming’. Any software company large enough needs teams like this. But maintaining these teams is expensive and hard. You’ll be paying for a lot of training, not to mention the wages. You’ll have to be at the top of your game to retain these guys and keep them happy.
All in all, I think it’s a nice idea I would love to see being used in real-life. If you work in a company that has such a team, feel free to share your experiences.