Recently in Software Engineering Category
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!
Peter Williams recently made a good proposal suggesting content-negotiation as a means to advertise and ask for version support. This is in contrast to using version identifiers in URIs as is commonly done. This is a neat idea. Peter's post prompted some debate and a rebuttal. But I find that this debate is a distraction.
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.
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.
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 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.
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.
Another nice articiel only Joel Spolsky can write A Field Guide to Developers. Here is my favorite part of this article:
Software upgrades are not fun. When you upgrade software, usually things go wrong, and you spend several hours to fix it. It seems that most users are not really surprised at this, and are prepared to accept it.