Here is another gem from Alan Carter of the Programmers’ Stone fame:

The Effects of Stress on Programmers’ and Groups’ Performance

One downside of working with experienced people is that, some experienced people tend to be opinionated, and the trouble with opinions is that opinions are, well, instantaneous reactions based on things they learned in the past. You can wake up an opinionated person and ask a question that you know this person has an opinion on, and that person (self included, on occasion) will most likely blurt out that opinion without even understanding the context. Unless careful, it is easy to get trapped into that mindset, and start enjoy being opinionated, and consequently, making or advocating "obvious" choices. Welcome to my soft rant!

Here is one opinion heard several times on the blogosphere. If X says that he/she had performance issues with this new cool website, the "opinionated" would immediately ask, "is that Rails based?" and without even waiting for an answer, would offer his/her expert opinion that "Rails is slow" and that X should use Grails, PHP, or whatever that person is currently a fan of.

No offense to the commenter, but I received such a comment when I blogged that I had performance issues with DreamHost. I did not buy the comment that Rails is slow then, and I don’t buy it now. There are other things that influence scalability and these vary from case to case.

Here is another example. In response to FaceStat scales!, the first commenter asks "Why on earth didn’t you use something like Grails that actually DOES scale?". I doubt if this commenter fully understands the architecture of FaceStat. To me, that is an automatic reaction, and so, I would be suspicious of that "obvious" choice that Grails or some other alternative would magically fix the scalability problems.

Say, for instance, if a PHP or a rails app is slow, an "obvious" choice is to throw memcache. But no amount of caching would rescue a poorly architected app. In fact, MySQL query caching may be sufficient for typical caching needs.

After writing the initial prototype of Cyclogz, I wanted to check if there are similar sites, and if so, how they are approaching the problem. The problem was simple – retrieve a large amount of data from a GPS, and then extract lots of info from it for both presentation and analysis purposes. I came across two sites (one of which is MotionBased, owned by Garmin). Both these sites did what seemed like an "obvious choice". Both sites upload all the data (in megabytes) to a server, store it in the database, and then kick off a background process to analyze and extract the data. This approach requires more hardware on the server side, more code to manage the background work, and more importantly, takes away instant gratification from the user. I won’t describe alternatives here in detail, but better and more scalable design choices do exist. It was also fun thinking about the alternatives, and implementing those.

Stefano Mazzocchi has a good write up about programmers and picking up colors. He is right. All the programmers I know, myself included, are awful at designing user interfaces with pleasing colors, fonts and layouts. Most programmers may not realize this – but programmers can’t get away from having these skills.

It is true that software companies hire skillful designers when it comes to user interface design. The designers can not only pick right colors and fonts, but also help improve usability and accessibility. However, there are times when a programmer needs to create an eye-pleasing user interface to sell his/her ideas to others. Given two equally competent programmers, the one with better user interface design skills may have a better shot at convincing that his/her ideas are worth taking serious. Imagine walking into a room full of skeptics ready to bash your ideas, and that first thing they notice on your demo are awful colors!

What makes software legacy? Two most popular answers are the age of the software, or the technology it was built upon. Looking at this question more critically, neither of these answers make any sense. For instance, some of the internet technologies are over 10 years old – does it make those legacy? Is Apache web server legacy? How about mainframes or Unix? Apparently these are not called legacy either – although each of these are quite old – way older than the latest buzz technology. How about software built using C or Perl? In fact, EJB 1.0, which is younger than, let’s say, C language, is considered legacy now. So, it is neither the age of the software nor the age of the underlying technology that make software legacy.

So, what makes software legacy? IMO, what makes software legacy is the change in assumptions. Most software is built around some assumptions (or use cases, in some cases) about its usage, its environment and so on. For instance, take my once-favorite editor Emacs. There may be still a large number of users vouching for Emacs, but I consider it legacy. In my view, it was designed for a different era for a different kind of software development with a different set of technologies in mind. For now, I think that is what makes software legacy.

I was thrilled to read about PlentyOfFish architecture at http://highscalability.com today. What impressed me most was the fact that an incredible amount of scalability was achieved completely ignoring a number of design qualities that web frameworks try to provide via layers of abstractions. This architecture just reinforces the idea that complex problems can be solved without complex abstractions.

I wonder if developers really need all those frameworks that try to hide the new from Java, the <a href="...&quot">...</a> from HTML or SELECT A, B, C from FOO from code?

During my years of software development experience, I have come across a number of developers and teams that feel unhappy that they don’t get to build a grand (and right) architecture to solve a given problem. At one point I used to agree with that camp, but over the last couple of years, I began to see this differently, and I now disagree with this attitude. During this time, I have come to accept one fact – that most software developers operate in bubbles and that their understanding of reality is imprecise, and that makes the developer unhappy and miserable.

Here I am not referring to small software initiatives that are run end-to-end by a small team. I am talking about larger initiatives that cost money and time to build, and you need real customers paying real money lined up to buy the software. I am also not talking about software that must live for decades after it is built without changes.

Let me take a simple scenario. Let’s say, a developer Joe walks up to to a program/product manager Bob and asks him this question – “Hi Bob, do you think this feature would be cool for product.” Bob may respond “yes” without realizing that that “cool feature” would add up x-amount of complexity or cost to the product without returning y-amount of benefit or revenue. An affirmative answer from Bob would make the Joe happy. In his view, it is the right thing to do, and Bob has just agreed. He would then go and build it happily for the next several months.

Instead, let us assume that Bob starts asking some probing questions – like the nature of the implementation, how would a user use it, how many users would love to see such a feature in the product, impact on schedules, market realities, what it means to the product road map and so on. In Joe’s mind, these questions are not so important because “implementing his idea is the right thing to do” for the product. At the end of a long and frustrating debate (frustrating for Joe, that is), let us imagine that Bob vetoes the proposal to build that cool feature. Depending on your team structure, Joe may be a product/program manager or someone who is a stakeholder that can veto product changes. A negative answer from Bob would make the developer Joe very unhappy. He would be thinking “these guys don’t understand why this is so important to do” and so on. Unfortunately, Joe is most likely wrong in drawing such a conclusion and here is why.

One important point to notice here is that the developer’s reality is different from the reality of whoever vetoed the developer’s proposal. The developer wanted to do some really important changes to product, that in his view would help the product in the long term. From a purely technical point of view, he may very well be right. The trouble here is that his view of the reality is partial and skewed. As a developer, he is very likely isolated from end users, their use cases, and their real problems. He is also most likely isolated from the cost of development and the operating realities. As a result, he may not have enough data to make a case for his proposals other than saying that he is technically right. The net result is misery.

My take on this avoiding this misery is to focus on funding and support.

As a developer, you have to get your users and other stakeholders fund your ideas. If you are unable to make this happen, and consequently if you are not allowed to implement your ideas, it is nobody’s fault other than yours. Your idea may be great on paper, but it may not be worthy of implementation if you are unable to convince other stakeholders and get funding. But how would you get funding?

That seems like a hard question – but there is very simple solution. Take one step at a time. Instead of trying to build the entire solution correctly and completely the first time, do it in iterations. Try to get the first iteration done as quickly and as cheaply as possible. Then wait for funding and support. They will happen if users and other stakeholders perceive your idea as being useful. Let users speak, and tell you what works and what does not. This has two advantages – firstly as a developer, it will let you test the waters and get a better insight into use cases. This improves your sense of reality. Secondly, it will make it easy to make the case for your ideas. In fact, your users may themselves make the case for your ideas. This approach is more realistic, pragmatic and avoids the developer’s misery.

This is also one reason I’m usually against building grand architectures to solve grand problems in big chunks. Grand architectures don’t matter if users are not with you. Get the users your way first, and then improve solutions bit by bit. At the end, you may not have the most elegant and clean architecture, but you will have something that works for the users who use it.

Here is an excellent post titled Don’t ask employees to be passionate about the company!. Management of a number of companies value loyalty to the company/team/group (i.e. passionate about the company) more than the employees being passionate about work. This post makes a comparison between good companies and good UI.

I am certain that one of the key differences between successful companies and not so successful companies is the way loyalty is treated. This quote from this post says it best.

I can not agree more. Companies should behave like a good interface, letting employees explore their creativity without getting interrupted with popups, alerts, crashes, hangs and so on. Companies should be like Mac OS X, and not like Vista, i.e. stay in the background and let me do my job better. Don’t keep interrupting me with things happening in the OS. Having switched to Mac from Windows+Linux about two months ago, I can now appreciate the role an OS provides its user. The Mac is like my place of work, not a tool I have to work with.

The sad part is that companies are not homogeneous in their values. There are always folks who value company/team loyalty over being competent, open and future-minded. When those folks start taking charge, watch out. That is one of the early signs of doom.

Carlos Perez at manageability.org posted an interesting discussion on OO-styled interactions, and I can’t agree more.

It is very common to find most people listing statelessness as one of the key principles of service API design. Statelessness is an overloaded term. To my experience, when someone says that a service is stateful, he/she usually means that the service maintains some internal state. We can argue all day long on whether maintaing state is good or bad – the answer usually depends on what the service is doing. In most cases, whether a service needs to maintain state or not is a service implementation choice – service users do not need to know or care about it.

From the client’s point of view, statefulness of a service usually implies that interactions with the service need to happen in some sequence to be meaningful, i.e. the client maintains some context with the service it is interacting with. Context is what a client should care about – not about whether the service is stateful or stateless.

Shared context makes service invocation interesting and meaningful. The service needs to define the context which may then be updated by the service or the client, and may even include references to any internal state maintained by the service itself. Services that don’t require any client-managed context are usually general-purpose utility services. Most usuful services need to depend on some share context to be useful. Context is what makes it possible to break a task into sub-tasks and let the client invoke sub-tasks in some defined sequence.

Some designers may prefer combining shared context with the inputs and outputs of service invocations. IMO, keeping the context separate from the data being processed and returned makes the service interface definition lot more cleaner, easier to understand, and extend. One problem with most programming models used for implementing services is that they don’t provide for shared context. For instance, take stateful EJBs. They are becoming extinct (rightly so) because they emphasize on the stateful nature and not on the shared context. With stateful EJBs, sharing the context meant that the client held onto the bean till the work is done. That is not the same as the shared context. Unfortunately, later layers like Java web services extended the same notion, and don’t provide for shared context within the supported programming models. You can easily bind a web service implementation to a class or a EJB, but you need to invent your own mechanisms for supporting shared context. Then there is the Web Servces Composite Application Framework, but I don’t think that is what service developers really want to worry about.

This also reminds me of The Need for Shared Context by Anne Thomas Manes, which argued for the need for defining a shared context.

Another harmful aspect OO-styled interactions that Carlos did not mention is idempotency. One of the problems with object-oriented development is that it is difficult to tell whether a given service invocation is idempotent or not.

Another nice articiel only Joel Spolsky can write A Field Guide to Developers. Here is my favorite part of this article:

I don’t hear people preaching this style argument often, but the best programmers I know and admire do follow this line of thinking.

Joel is so right about developers’ perception of politis. It is all about making just choices . Ranting of any kind usually starts with something or other not being, well, just – listen up managers!