Wille Faler’s Buzzword Bingo

I have been evaluating IntelliJ IDEA for the past couple of weeks, and it is a great piece of software, if somewhat pricey and a few rough edges (code formatting and lack of complete round-trip compilation being two of them).

I considered buying a license, but noticed that they only allow upgrades for bug fix and minor number releases on a license. A major number release requires buying a license upgrade. I e-mailed JetBrains sales to verify this so I was not missing anything, and sure enough, my analysis was correct. With their planned release of IntelliJ 9 in Q4, this means I would require an initial outlay of £180 for the version 8 license, and a further outlay of £100 to keep up to date in the next 4-5 months with the upcoming version 9.

This is a schoolbook case of how NOT to get me to buy their product. I have no interest in paying twice for the same thing in less than six months just to keep up with versions, especially when the one-time price alone is steep enough. I’ll stick to NetBeans, thank you very much.
This might seem like I’m singling out JetBrains for criticism, and I have to re-iterate, I love their products, just not enough to pay for it twice in a year to keep up.

Anyone who works in software development will know one thing: version numbers, especially major version numbers are completely arbitrary and rarely reflect much else than deadlines and/or requirements from the marketing department. Selling licenses based on major version numbers, especially in a business where they come frequently is braindead.
In this case, I would have paid the £180 license cost in a heartbeat if I knew I had free upgrades for say 12 months from the date of purchase. I’m not paying £180 if my upgrades are going to be subject to the whims of a marketing department, especially in a global recession.

If you are selling licensed, installable software, the way to get my business is to guarantee me an upgrade path for a given amount of time. If I have to pay for upgrades, especially when a new version is on the horizon, it only means that I’ll hold off on my purchase in the best case (which means you won’t get my money for a while yet), worst and most likely case is that I won’t buy at all.

Users these days are too smart to fall for the version number game, so if you want their business, give them a clear upgrade path.

I firmly believe that Agile practices, both in project management and software development are the best way to go for software projects.
However, in the debate about project methodologies, one thing often goes amiss: project size.

I would be very interested in seeing some firm numbers on project success rates on large vs. small projects for both Agile and “traditional” projects. My gut tells me that size has a lot more to do with project success or failure than any methodologies applied to a project.

As a rule of thumb, most projects I have been on in my career have followed a simple path: projects of limited scope with up to about 7 people have generally been successful with few major problems or setbacks. Projects with more than 15 people have generally been failures on some level and marred with trouble – either “just” delays and budget overruns, or outright failures.

This leads me to the simple conclusion that the best way to succeed with a £20 million project is to not have one, but instead have lots of small £200000 projects that work in isolation.
A smaller number of people, stakeholders, smaller scope and shorter timeline will all go a long way towards lowering complexity, coordination overheads and increasing accountability.

On any project, my order priorities would be (better) people, (smaller) scope, (good) methodology/practices. No amount of good process can do much about bewildering complexity and leviathan-like scope.

Some would probably look at my entrepreneurial exploits and come to the conclusion that I seem to be more prolific in building things than I am successful in selling them. Both I and my bank account would be inclined to agree.

However I do not perceive it as failure for a number of reasons: first of all, I learn something from every attempt, for each attempt I get closer to learning a formula that will give me the success I eventually want. And let’s face it: I don’t really risk getting wiped out from my attempts, they are low risk, low cost, hardware and bandwidth are extremely cheap these days, break even on running costs are just a few customers away. My only real investment tends to be a few hundred pounds and the time-value of my own time.

Secondly and more importantly, I tend not to build stuff for “others”, I scratch my own itches, I am always my first user myself, I build things I want to use myself, or at least things I think I want to use. I build things I want to use because I see other alternatives either being absent, lacking or questionable.

As long as you scratch your own itches, chances are there will be others with the exact same itch. And if there aren’t, at least you will have scratched your own.

Anyone who has been reading this blog for a while will know I am a big, big, big fan of Apache Wicket.

Besides the technical merits of true object oriented web development and productivity on a level way beyond that of brain-dead frameworks such as Struts 1 & 2, JSF, Spring MVC et al, Wicket did something else for me: it re-awakened my entrepreneurial spirit.
I started out working for startups in my first few years of working, I even founded one myself, it was something I enjoyed immensely and always wanted to get back to. The problem for me was I didn’t know how: most of the ideas I got where web based, and for years I had shunned web development because it was such a bag of pain – Java based frameworks where braindead, PHP et al where not really an option for someone who hated doing markup. I kept procrastrinating with my ideas because I realized that implementing them was just going to be painful and boring given the technology choices I was aware of.

But then I discovered Wicket, web development became fun again. It might sound like an exaggeration, but it’s not: Wicket can be attributed for getting my ass up (or is it down into the chair?) and starting to implement some of my ideas.
Granted, my success so far has been limited – I’m making a small profit on my webapps, but hardly anything to write home about, but that’s not the point. The point is that Wicket made it fun again, I’m putting my ideas to work, creating, trying things. If I can only get a bit of luck and improve on my marketing & sales skills, I’m sure at least Ramen profitability and beyond from my webapp efforts is within reach.

Target Process had a good post recently that questioned the need for deadlines.
I’m inclined to fall into the camp that says that deadlines are wholly unnecessary.

No, this does not mean that developers should be allowed to “perfect” software for ever with little or no accountability. No it does not mean that you stretch out deployment until it is deemed to be “ready” after months and months of work.
My take is the opposite: Every iteration should end with a production deployment. No exceptions. Ever.

Deadlines are most of the time an issue of poor scope management – rather than aggressively manage scope while at the same time not accepting stories/features that are not production quality, organizations make up arbitrary deadlines that will have an arbitrarily large set of features in.
What would be more desirable in my opinion is better scope management and better engineering discipline to make sure code is always production quality. That way deadlines loose their meaning as a production deployment can be made almost at any time, with any set of completed features.
Someone might argue that some features are “all or nothing”, but I would still claim that this is still a case of people being too careful to slice and dice aggressively enough – surely there is some minimal subset that is good enough to either do the job, or at least not interrupt anything else if it exists with minimal use?

Deadlines can be done away with almost entirely, but it requires a combination of engineering- and management discipline to do the right things and do them right most of the time.
The real hurdle isn’t an arbitrarily large set of features some months down the line, the real hurdle is overcoming our own tendency to loose focus and discipline to do things right.

It seems the best source of information, pictures and video from the events in Iran are produced through citizen journalism – All these pictures are from Twitter (found through Twicsy).

Old gender roles don’t seem to matter. I have a feeling the picture above might become as symbolical for the current event as the picture of the student in front of a tank at Tiananmen Square. Although I pray the outcome will be different this time around.

Mousavi supporter helps evacuate an injured police officer. A human side to the events.

I pray that the Iranian people get the inalienable freedom that is the birthright of all people with as little bloodshed as possible…

As an industry, the software industry is hooked on complexity for the sake of making us feel important and technology for the sake of technology.
Rather than stopping for a second asking what the problem we are trying to solve is, we often use the problem as an excuse to concoct overtly complex “solutions” to the wrong things altogether.

If your problem is notifying someone or something of a system event, do you really need to come up with your own network protocol when protocols and messaging systems are abound (if it’s a person who needs notification, e-mail perhaps?…)?
If your problem is rendering a website, do you really need to hit a database every time, create a bunch of objects every time and pass through 8 layers of “architecture”, when serving a static html-page would do just nicely?
If your problem is binding an application together, do you really need to externalize every object creation ever into an xml-configuration file, when calling the “new”-operator might just do the trick?

You don’t actually have to retrieve all the data all the time from a database, just because a database is there. You don’t need to have everything pass through 8 layers of “architecture”, just because someone put them in a powerpoint at a time when your project was just a twinkle in the Product Manager’s eye. You don’t have to invent yet another network protocol just because you think you can.
Easy and simple will do it.

I’m pretty sure the purpose of any project is NOT to “shuffle 1 and 0’s through as many network and application layers as possible” while waggling your genitalia in the general direction of the new shiny “LookHowSmartIAmAdapterConfigurerManagerServiceFactory” you wrote in the hot framework du’jour.
What are you actually trying to do? What is it that you want to achieve? Those are the questions you should ask, rather than what new shiny things are being hyped in industry media.

I keep getting back to one thing a lot – the case for very frequent releases of software on ANY software project.

I can point to a specific point right now: I built TweetSift – a link feed and bookmarking service for Twitter over the last week or so. I envisioned it as sort of a “Delicious for Twitter”-service. Once I deployed it and started using it myself and saw others use it, I immediately realized a couple of things: it was missing some essential usability features that I thought it needed after some use, and secondly that both I and other users actually used the service as a “feed reader” of links people where tweeting more than as a bookmarking service.

These things came as a complete surprise to me, especially how both I and others ended up using the service in the form that it was early this week.
I definitely want to leverage the aspects of unexpected use and I can see a strong case for it: following and tagging links on Twitter is like RSS on steroids in terms of finding interesting content – you follow people with similar interests to begin with, so the likelihood that they will tweet links of a certain quality is much higher than just blindly following hundreds of RSS feeds.
But as much as I can see the case for it now, I didn’t have a clue that it was there before it struck me in the face! And I built this service to scratch my own itch to begin with!

To digress a little, I solved my original aim while keeping the unexpected use through introducing three read states for links: All, “Feed”, and “Bookmarks”, where users can either see All items, just the ones they have not yet explicitly saved, or the links that they have explicitly chosen to save by clicking “Save as Bookmark”.
I never saw the need for this feature until today, but now I think it might be the most useful feature on the whole service. On the flipside, before I released, I saw “needs” for lots of features I thought would be critical. Now that I’ve used my own service for a while, I’m not so sure they are actually needed.

So the point of this post is: If even I can’t know what features I want for software that I write for myself before I have tried the software I wrote, what are the hopes of anyone getting software right without frequent releases when they write it for someone else than themselves?
Most people won’t know what features they want and need until they smack them in the face from actual use, at the same time the features that seemed critical may be completely obsolete and useless once you try them for a while.

In most development organizations that are larger than just a few people there tends to be an ongoing conflict in design between database people and object oriented developers, let either drive and control the process too much and you have a problem on your hands..

If the DBA’s are allowed to drive the application design process, you can be sure that you will have an unmaintainable application where most of the application logic resides in stored procedure and database triggers – a nightmare to maintain.
If on the other hand you let the developers based in the OO world drive the process, you can be sure that data structures will be hierarchical nightmares and performance a complete and utter dog.
It seems to me that this conflict often stems from a lack of cooperation, where database people and developers somehow think they have irreconcilable differences that demand that one group take complete control over the design process.

Does it really need to be this way? I have never understood why people have such a hostile attitude to someone else’s knowledge and domain of expertise. Database people tend to be really knowledgeable at, well, data storage and retrieval, whereas software developers tend to be better at structuring software. Why not leverage the overlapping competencies?

Lately, I’ve been picking the brains of a MySQL expert quite a lot, whenever I need to access or write to a database and I am unsure, I have asked him what the best way to achieve my desired result is from a relational database perspective. Suffice to say, I’ve enjoyed the process and learned quite a lot about the inner workings of MySQL in the process beyond a level I ever knew before.

Don’t let the DBA’s OR developers entirely drive design if you have both competencies in house. Having them as equals, learning from each other and providing expertise where they know best might be a surprisingly enjoyable process.

I spent the better part of the weekend building a bookmarking application for Twitter – think “Delicious for Twitter”: it will automatically parse your Twitter stream/timeline for links, save them, tag them with any hash-tags (#tags), and you can also setup automatic rules that allows you to auto-tag links based on who tweeted a link. The application will also parse the title link of the destination page, giving you a better picture of where the link goes and what it is about.

You can find the service here: TweetSift.

I intend to improve upon it based on some early feedback and realizations I have made myself, next up is bulk deletion and bulk tagging to further ease the management of links/bookmarks.

For the technically interested: it is yet another app built on Wicket and JPA, running om Amazons cloud platform.

Enjoy! And please do spread the word if you like it!