Book Review – The Accidental Billionaires

Posted in: Consulting & Entrepreneurship, Social Networking

This book is a fascinating look at how Facebook started and what it means to go from a college dorm room to a multi-billion dollar valuation in just a few short years.

It is not surprising that there are some casualties on a rocket ride like that, but you cannot explain away all of the deception, backstabbing and betrayal that easily. The book points a finger squarely at Mark Zuckerberg the original brains behind the operation, as the likely cause of many of Facebook’s troubles. The book does elude to the irony that is someone like Mark Zuckerberg, who is by all accounts socially awkward if not entirely inept, running the biggest social networking site the world has ever seen.

The book is a work of non-fiction (or near non-fiction), but it reads like a fiction novel and is easily digestible.

I am the first to admit that I resisted the lure of Facebook until late in 2009, so I was kind of late to the Facebook party. Now with all of the bad press Facebook has been getting lately because of their seemingly cavalier handling of their user’s personal data, I am starting to question whether I made the right decision to create an account at all. This book clearly raises the question as to whether you should be trusting your personal data to Mark Zuckerberg.



Quote Of The Week – 2009/11/13

Posted in: Quotable Quotes

“Good enough” software is rarely good enough. It is a sad manifestation of the spirit of modern times, in which an individual’s pride in his or her work has become rare.

Niklaus Wirth
(From an interview in Software Development, June 1997)

Coding Standards – Quality From The Ground Up

Posted in: Software Development Best Practices

Coding styles are THE religious debate of the Software Engineering industry. Everyone has an opinion, but no one has an iron clad argument as to why their ideas are better than someone else’s.

It doesn’t matter what language you write your code in or what company your work for or even what open source project you contribute too, the topic of coding styles will sooner or later raise its head. The debate can range from the banal, like which line the curly brace goes on, to the overly subjective, like how to name variables.

In the end most of the decision points are pretty subjective and it is somewhat irrelevant what you choose, as long as everyone agrees and you are consistent. But don’t be mistaken, a consistent coding style is an important consideration on any project, from the solo developer to the multi-national team.
Continue reading »

Breaking The Ties That Bind

Posted in: Personal Branding

Today, KLSX a radio station in the Los Angeles area announced that they are switching formats from all talk, to some kind of Top 40 music format. Due to the sorry state of the radio market in most of the US, especially on the music oriented stations, I have been listening to KLSX pretty regularly over the last 18 months or so. So I have been listening intently today ever since the morning shift to hear each DJ’s take on the situation.

There has been one common thread through all of the shows today and that is that they have been encouraging their listeners to visit their web pages once the station goes off the air on Friday night. Adam Carolla who does the morning shift stated quite clearly that starting Monday morning his show will continue in podcast format, basically uninterrupted. Frosty, Heidi and Frank who do the midday shift were also encouraging people to visit their website, where they will post updates of whatever it is they do next.

Now, KLSX is an interesting station and may not be run like many other stations. For example it is very interesting that each show/personality on the station really has their own online presence outside of the station’s own website and were allowed to promote their own web presence openly.

It changes the model, through the use of the internet, that these DJs really were much more loosley coupled to the station they were on. This means they could easily take their show, and their listeners to a new station with only minor cosmetic station identification logo changes on their own websites. The radio station itself in this case has simply become a vehicle for the DJs to deliver their own content.

It of course is an interesting time for a radio station, who by all reports was doing well in the various timeslots, to make such a dramatic change. The satellite radio market is on the verge of collapse and if it does go under, there will be a glut of DJ personalities running back to find a safe terrestrial home.

On a personal note, I have been thinking how similar my own situation is to the way these DJs were operating. In addition to my work with The Juggernaut Group, I have a day job. I also do contracting work on the side and I help to write this blog – none of which is in any way connected to my day job. If I were to get laid off from my day job it would have very little influence on my online presence. Any good will I have generated through my online presence would continue on. Anyone who wants to do business with me would easily be able to find me via the internet, no matter where I went for my next gig.

I have essentially become much less connected to my day job. My credibility and hence ability to find another position has much more to do with my online presence than my previous employer ever will.

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.