Archive for December, 2011
Okay, now that I got the link-bait title out of the way, I am going to rant just a little bit. I imagine that I’m like most of you and I think that some flavor of agile (little a) is really the best way to develop software.
I think that collaborating with the business and getting things in front of them as soon as possible so that you can make changes to it as you go is a very valuable model. I am also very much for the short release cycles that most agile shops prefer.
What I despise, however, is what I call “Agile as Snake Oil”. There are a lot of disreputable companies that are putting the word out there that all you have to do is hire them and they can “sprinkle a little agile” on your project or your company and you will magically get everything you want.
They crow that Agile means that you can not make up your mind on what you want until the last minute because Agile Developers have to do what you say and are bound by the Laws of Agile to always change the software for the client. They want their cake and to eat it, too. They want all of the spec changes and none of the timeline changes or compromises.
Oh, that they would actually read something like Robert C. Martin’s book, Agile Principles, Patterns, and Practices. I’ll tell you what, I think that if people only read the end of the book, where Uncle Bob tells a tale of two cities, a project where the team does a “traditional waterfall approach” and the same project where the team practices an “agile approach”, it would make a world of difference.
As you can imagine, the waterfall approach ends in disaster, with stress and hard feelings abounding. In contrast, people are satisfied – almost happy – with the agile approach. The HUGE takeaway from the agile story, however, is that it was not a 100% win for either side. They did not hit their original deadline with 100% functionality. Features had to be traded in if the timelines could not move. However, the business stakeholders were the ones who went ahead and made that call.
I covered this in my last “Agile” post over a year ago, but I think that it bears repeating. Every agile project should do these steps
- Gather requirements
- Estimate requirements to determine length of project
- Work requirements in iterations
- Gauge velocity in coding requirements against estimate
- Determine whether your velocity requires you to either cut requirements or extend timelines
- Lather, rinse, repeat
Developers always get a bad rap for number 5 and it is always largely based on our lack of skill at number 2. Estimating is something that developers really should improve on, however, the business needs to understand two major things. Number 1, those timeline estimates are based on developers being able to work on the project at “perfect world” capacity – meaning 75-80% of their time. If developers are interrupted with conflicting priorities, original estimates and timelines are null and void.
Second of all, those who live in glass houses should not throw stones. If the original requirements are so ill-planned that they need to be drastically refined or changed, then developers should be able to refine and change estimates, too, since they are basically working on a different project than the one they started with.
There are obviously no perfect people in this world, so that means that there is no perfect system. Any system will invariably break down because of those imperfect people going around and “being human”. That being said, the best way to get to nirvana is to act like the participants in Uncle Bob’s Agile Story and rely on the two C’s, “communication and compromise”.
Compromising is the original agile. Be retro.
Harvard Business Review published an article at the end of last month titled Building a Mobile App Is Not a Mobile Strategy. The TL;DR; version is that mobile is not an item to be marked off of a checklist. It is bad if your company just created a mobile app so that you can answer “yes” when the CEO asks, “Do we do mobile?”.
I heard someone speak at a conference here in Ohio who was making this same point. Some time ago, the best visual medium for advertising was the print ad. Since that was the end of the standard understanding, when the web came about, people set out to put up what we now call “brochureware”. Basically taking their magazine ad or brochure and putting it up on the web. No real interaction and no reason to ever have a repeat visitor. Hey, but at least they had an “Internet Strategy”, right?
The same thing is happening now. Mobile is hot, so people are trying to create mobile apps that are nothing more than advertisements or brochureware for their product or business. Not a lot of people “get” mobile yet, so the good ideas are coming slowly. However, just as companies began to create interactive websites that provided a service or amusement while educating or advertising their service, that time will arrive for mobile, too.
Even now, forward thinking companies are getting it. The article mentions Proctor and Gamble’s sponsorship of a 3rd party application called “Sit or Squat” that helps locate public restrooms wherever you are, while at the same time keeping Charmin at the forefront of your mind and associating it with the best possible restroom experiences.
Having an idea or a strategy for what you will do to “accomplish” mobile is great, but the Harvard Business Review article pretty much stops there. In my opinion, the key to having a dynamic and impactful mobile strategy isn’t just how you will market to consumers. It encompasses how your employees will be productive. What sorts of applications could your employees use “on the go” (in meetings, during travel, etc) on a smartphone or tablet device? How will you deliver those applications to them?
The other big key to a successful mobile strategy is integration with your existing business platform. What sorts of services or APIs does your organization have exposed to allow mobile applications to integrate with your systems? If you have none, what would it take to create them? This to me is the heart of a Great Mobile Strategy in the Enterprise. It is mobile as an integrated natural evolution of your systems in a way that encourages productivity and growth. And that is the hard part.
If you aren’t in a place where new applications can integrate with you, then you are in a place that is stagnant. If every new application has to tear down and throw away what came before it, you are asking to fall behind. A Great Mobile Strategy starts with a Great Overall IT Strategy that allows mobile to become not just something “checked off” or “bolted on” but a full-fledged member of your company’s application stack.
After reading this article that I saw on Hacker News some time ago, it really got me thinking. The gist of the post is that “Great Judgement” is the number one trait of a great developer.
There are a lot of developers who only want to do the “latest and greatest” thing. They practice what I like to refer to as RDD, which stands for Resume Driven Development. Every project is just a way to make their resume that much more enviable. It is even a little hard to fault these people at first blush because in the IT industry, if you aren’t pressing your skills forward, you are quickly becoming irrelevant. However, sometimes developers forget that they are being paid to deliver a solution for a client or employer. The client’s needs should always come first.
Are you doing work for a PHP and MySql shop? Could Ruby or Node or Cassandra help them solve their problem? Sure, but their existing code is in PHP, their on-staff developers know PHP, and finding PHP developers to hire is easier than finding a good developer who knows Node or Cassandra. You may very well be doing them a huge disservice by building them a “blazing fast web scale” solution.
That’s where Great Judgement comes in. New technologies may offer benefits, but there are always trade-offs in technology. The first is your own knowledge. If you are very familiar with C# and .Net and don’t know Ruby, but you try to put together a Ruby on Rails solution for a client that isn’t mandating Ruby, you are very likely going to cost them time and money while you deliver more slowly, let alone any mistakes you are sure to make or hard-to-maintain patterns you might leave behind because of your inexperience.
The second trade-off is the number of available developers to maintain and build upon your code. The system may really hum when you write it in Brainf*ck, but you just pretty much made sure that there are maybe 30 people in the world who could help that company maintain or grow it. Larger companies aren’t as susceptible to this as smaller companies because they usually have rigid standards in place, but the “market” for your code – be it the language, the framework, or even your patterns – should be at the forefront of your mind as you plan.
The third trade-off is not to over-engineer. Some developers want to create a highly robust and scalable system with a caching layer, failover clusters, and load balancing for every one of their solutions. They want a pluggable architecture and a side of fries with that. The problem is that they are making a small inventory application for the secretary to maintain her office supply levels for a staff of 9. Sad to say, but a simple Access database that would take an hour of your time to create may be all that they need.
I haven’t thought enough to actually assign Great Judgement as the number ONE trait of a great developer, but I definitely have to agree with the author, Tammer Saleh, on many of his points. If Great Judgement isn’t number one, it is certainly in the team picture. If you use Great Judgement, you are a long way to delivering valuable solutions to your clients and that may improve your resume way more than buzzwords.