Why Marketing Is Too Important To Be Left To The Marketing Department

Posted in: Consulting & Entrepreneurship

I just finished watching this exceptional presentation by Seth Godin (http://sethgodin.typepad.com/).

If you are a software developer, software entrepreneur or even a marketing person that works with a software team, I am confident you will get something out of this.

The presentation is from the Business of Software conference (http://blog.businessofsoftware.org/) in 2008.

links for 2009-06-22

Posted in: Social Networking

Twitter Recap for Week Ending 2009-06-15

Posted in: Social Networking

JavaOne 2009 – (Mostly) Important Questions (Mostly) Answered

Posted in: Enterprise Java

A few days before JavaOne I posted some questions that I was looking forward to finding out the answers too. Here is what I found out.

Has Hudson Killed CruiseControl?
I saw a couple of presentations on Hudson. I also saw Kohsuke Kawaguchi at the Thirsty Bear and he was drinking the good beer, so clearly Hudson is verging on world domination under his guidance.

I never saw Cruisecontrol mentioned anywhere. Not in the conference catalog and not in the pavilion.

I am now even more convinced that Hudson is the way forward for open source Java Continuous Integration.

What Will Be The Volume Of The Twitter Noise Coming From Inside The Conference?
There was definitely a strong stream of Tweets around the #javaone keyword all week. I was able to get a different perspective during the General Sessions by watching the Twitter stream go by as people Tweeted about what was being said on stage.

But what I will say is that I was able to keep up with the volume of Tweets. I mention this because I started to try and follow the #wwdc keyword this week as the Apple conference was going on and I simply could not keep up, not even close. Every time my TweetDeck was refreshing, I was getting more than 100 Tweets during the opening keynote. I gave up in the end and turned the live search off.

Also, while I saw some people Tweet about “is there a Tweetup?“, I never actually saw anyone take the bold step to be the organizer of one.

So definitely more Twittering going on, but nothing earth shattering. I was also hoping to see a vendor try and use Twitter as a medium for some kind of viral promotion during the conference, but I didn’t see anything that creative unfortunately.

Will AJAX Presentations Be THE Place To Be Seen For A 3rd Year Running?
So there were definitely a lot of AJAX based presentations. There were also a lot of REST presentations, which (at least in my experience) seem to always stray over into the AJAX world.

But there were also probably an equal number of JavaFX presentations. Although I would take the amount of JavaFX presentations and other buzz with a grain of salt as it is Sun’s pet project and it was their conference.

There was even an AJAX vs JavaFX presentation to round things out on that front.

But I do think my prediction of all topics related to the cloud as being the hot topics of the conference was probably correct – probably only outnumbered by speculation related to the whole Sun/Oracle situation. There was a track on the Monday morning related to the cloud, there was an unconference on the Monday afternoon called “Cloud Camp”, Sun showed off cloud related provisioning in the Tuesday morning keynote and there were a whole pile of regular sessions either related to new cloud topics, or just repositioning old topics to add the buzzword cloud to their repertoire.

What Will The Oracle Presence Be?
So a bit of a mixed bag on this front.

As most people who care already know, Larry Ellison made an appearance at the keynote on Tuesday morning. I was actually rooting for him to not show up at all – I think that would have been the best play for Oracle. I think McNealy played it well, but it was obvious that both men were a little uncomfortable and they stumbled on some awkward topics during the time they shared the stage. I don’t actually think Larry really cleared any of the FUD related to the situation even though he tried to reassure people that Oracle “likes” Java.

Beyond Larry’s appearance though, Oracle’s presence was actually less than previous years. Most notably, Oracle had absolutely zero presence in the pavilion this year. You can speculate to heart’s content as to why that was. I believe there was at least one session from Oracle personnel, but I did not make it to that one.

I didn’t see any Oracle signage around the conference, it pretty much was business as usual from that standpoint.

What Will The Reaction To The Microsoft Keynote Be?
This turned out to be a dud when compared to the chatter leading up to it.

There was little reaction from the crowd, although from my quick eyeballing of the room, it seemed to be the smallest attendance for keynote during the week.

Basically Microsoft told us that integration is import – wow, thanks for that, welcome to the party. The rest of it was a thinly veiled marketing pitch, which never goes over well at a technical conference.

Will Jonathon Schwartz Look As Uncomfortable And Awkward As Usual?
Believe it or not, I actually think Schwartz did a reasonable job on the Tuesday morning. It didn’t feel quite as stiff as usual. His interaction with partners etc. was still a little cumbersome but nothing worse than I have seen elsewhere.

I was super happy to see Scott McNealy make an appearance – it was clearly the highlight of the keynote. I also think Sun made the right call to have McNealy be the one to address the elephant in the room. The standing ovation he received when he left the stage I think was evidence of that and was also the highpoint of the whole keynote.

Will James Gosling’s Toy Show Seem Overly Long And Desperate Again?
The toy show was the same old story as expected. I sat through it and there are some interesting niche type Java things going on, but I still left the session with overwhelming sense of “meh”.

I think the most interesting part of the Friday morning keynote was the fact that there was absolutely no acknowledgment of the Oracle/Sun situation at all, nor was there any acknowledgment that this was probably the end of JavaOne, at least as we know it today. I had predicted the Friday morning keynote to be somewhat emotional with a bunch of farewells and look-backs, but as it turns out, the Tuesday morning keynote was the one that had the emotion in it.

Will The Lunch Lines Be Under Control?
Nope, lunch lines were ridiculous as usual.

I am always impressed at how megalomaniacal the event staff get at Moscone during these big conferences.

Will It Be Crazy Cold in Yerba Buena Gardens on Thursday Night Again?
I was way off on this one.

The weather was forecast to be horrible on Thursday and so the event staff moved the party to the ballroom at the Marriott on 4th street. As it turns out it was perfectly dry on Thursday and it could have easily been held outside, but it was certainly cold.

The party was actually pretty good and the band was excellent for the setting IMHO and the food was significantly better than last year’s corn dogs and popcorn.

Will The Bookstore Be Given More Space?
Nope, exactly the same space, exactly the same pushy-shovey experience trying to browse the books.

Will Enough People Use me As A Reference So I Can Get The Better Swag?
Unfortunately no. :(

Why are the A’s and Giants both playing away all week?
The MLB has declined to comment on this obvious conspiracy.

Stay Out Of My Business!

Posted in: Software Development Best Practices, Software Development Team Leadership

If you have a software team in your company, it is (hopefully) stocked with highly trained engineers that are well paid and know what they are doing, or know how to figure out what to do in a timely manner. They offer the best value for money to your company when they are empowered to make technical decisions, after all, if they are not the technical authority in the company, then what are they there for?

It doesn’t make much difference if the company is an ISV or an internal IT department serving internal customers only. At the end of the day, you have a software team serving customers by providing software based solutions to their problems.

The customer’s role is to provide what are normally called “user requirements” or “functional requirements” – in other words they need to tell the software team what it is that they want the software to actually do for them. It stands to reason that the customer is the best person to ask what the software they are asking for should do.

Now, it is very common that the customer struggles to tell the software team what it is they want. Either they really don’t know, or they think they know but turn out to be wrong. Both of these “incomplete requirements” scenarios can be handled using an agile development process so they should not present a big hurdle for a competent team. The basic premise still remains, the customer’s job is to provide functional requirements, no matter if they give them all up front, or piecemeal along the way.

From those requirements, the software team is charged to implement a solution that implements those functional requirements. As I proposed above, a software team designing and implementing software is the highest and best use of their time. So this scenario sounds like the perfect environment for quality software to thrive.

Of course finding a company that fosters this environment can be hard. Often the culprit that violates this nirvana of quality software is the customer that doesn’t quite know where their responsibilities begin and end. You can smell this happening when functional requirements documents contain statements that refer to specific technologies or architectures. For example, a functional requirement that states “The UI will be implemented using technology ‘X‘ because it is the only one that can handle the requirements” should be an immediate alarm bell. It seems benign, but there are many problems that can manifest from a requirement like this.

The obvious first problem is you have a group who are not the technical authority making technical decisions. This is a political, social and morale issue. Technical people like making technical decisions, that’s why they are technical people and not marketing or sales people. If you take away their ability to make technical decisions they are likely to resent it, their buy-in for the project will drop, the morale will drop and the result will be an inherently lower quality output.

Another problem is that you have less qualified people making technical decisions. If your customer is more technically qualified than your software team, you are probably doomed before you begin. If this is the case for you, forget reading the rest of this article and start polishing your resume. A good software team should contain members that are relentlessly exploring new technologies and trends. Without question your software team will have a deeper knowledge of all possible choices and the ramifications of one choice over another.

Software teams contain a lot of knowledge that is not necessarily written down in policies, procedures or architecture documents. This latent knowledge base is the main value of the team. It would be impossible for an outsider to posses most of this knowledge, particularly the knowledge that is specific to this team as opposed to software in general. The reasons behind certain tradeoffs made 2 releases ago can be a critical knowledge point to have.

This latent knowledge is a double edged sword though. I have seen many meetings between customers and engineers where an engineer will discount a suggestion from the customer, and when the customer asks why the engineer struggles to answer even though he has the knowledge. I like to think of it like breathing. You know that breathing is remarkably important, in fact you do it all the time and you really couldn’t imagine doing anything else. And yet if someone asked you how to breathe, it is quite difficult to explain, particularly if you are talking to an alien that doesn’t have lungs and doesn’t understand the basics of human respiration. Well that might be taking it too far, but the point is valuable. Another analogy is a human trying to explain their existence to an ant. Ignoring the obvious communication issue, the conceptual argument offered by the human is completely incomprehensible to the ant because his reality is so different to the human. So basically, trying to explain software development to a layman is often difficult simply because you have no common reference point and no common language to use. If you try, you will often cause more harm than good.

So is there a time when a customer should define technical requirements? The answer is a definite yes, with a closely followed maybe. A customer can have legitimate constraints that need to be observed. Call them “environmental requirements”. For example, needing the software to run in a Windows environment because that is all the customer has on their 2000 desktops, is a reasonable requirement for the customer to have.

A requirement stating that the software must be browser-based because the customer’s IT department doesn’t want to have to install the software on the 2000 desktops also sounds reasonable. But then the question for the software team is, what does “browser-based” really mean? What if the software could be developed using something like Java WebStart (a sort of browser/thick client hybrid), is that going to be acceptable? What if the software is inherently better delivered that way because of the rich UI that is possible? Clearly this second requirement could restrict the choices of the software team to the extent that the quality of the solution may be affected. The key is to get at the true underlying requirement. If the requirement was restated as “The solution should have a zero-install profile to reduce TCO”, then the software team can achieve the requirement and still have their hands untied to find the best technical solution.

Is the opposite true? Can the software team impose functional requirements on the customer? Again the answer is a definite yes with a closely followed maybe. If the development process is one in which the requirements are written up front and development happens later, then input from the software team is very difficult to take into consideration. Don’t forget, the software team is usually the first ones to use the software being constructed as they test their code. They will often find design defects very early on. Being able to provide that feedback to the customer is highly valuable. That value increases exponentially in an agile development environment where that feedback can be acted on quickly. In the end, the functionality needed is the customers decision, and suggestions from the software team may be ignored for very valid business reasons. Software teams simply need to swallow that pill, you can lead a horse to water …

I have talked about the highest and best use of software development team resources, but the opposite is also true for the customer. If the customer manufactures fridges, then the highest and best use of their time is working with fridges. If the customer is the internal marketing team, then the highest and best use of their time is doing marketing things. If that isn’t the best use of their time, then they are on the wrong team.

The quality of the output of a software project is improved when customers and developers are aware of their responsibilities and work within them. The quality is improved exponentially when customers and developers are also given the ability to provide feedback in both directions and when the development process empowers both teams to act on the feedback quickly.