Comments (0)

By Krishna, November 29, 2009

Anecdotes are dangerous. Scott Koon has one about fixing a doorknob, linking it to the now-infamous Spolksy duct-tape programmer post and writes:

Think about that the next time you reject a new programming tool because you think it might take too long to learn or it’s different. Instead of doing the hacky way you KNOW will work, check to see if there is a more elegant or permanent solution. Because if you aren’t careful, your cheap and easy workaround might end up sticking around in the project long enough for it to become a problem to you.

People keep missing the point. There is a situation where we have bad programmers who use whatever tools they know to get things done. Everything about that situation is wrong because you have bad code – lengthy, mangled, unmaintainable. There is no argument about what should be done to those developers.

The other situation (and what the real argument is about) is the case of an experienced developer who has been successful in the past and who would rather use what is working for them than use something they are unfamiliar with. Because the tool has been successful for them, they do not accept that it may become a problem in the future. An example could be as simple and recent as an ASP.NET developer choosing to continue with WebForms than use the (arguably better) MVC framework.

Choosing to dismiss an experienced developer’s older tool as a “cheap and easy workaround” is a misunderstanding of the situation. The old way of doing things may have been the gold standard a few years/months ago. The new tool may work better, but only for a person who has spent enough time learning it to master its nuances. And there may be many such new tools, each of them making extravagant promises. So we also have the problem of making the right choice.

In a sense, this is the classic Technology Adoption Lifecycle problem, having to do with how fast people accept new technologies.

Technology Adoption Lifecycle (CC Wikipedia)

This was for firms using a particular technology, but it could apply to programmers moving to new technologies. When do they think a particular technology is good enough for them? Or when the current technology is unsustainable for them?

Comments (2)

By Krishna, November 17, 2009

Zef Hemel writes about the inscrutable error messages that he gets when making typos in Ruby on Rails, Scala and JBoss Seam. I recently saw a new programmer struggle with the RoR errors and I have been a victim of some of the problems that occur when you type a string wrong in Java. For those who have had the same experience, it can be deeply frustrating to realize that you spent a whole day debugging a typo while managing only to spend minutes on the application logic.

Looking at some of the comments on his posts (especially the RoR post), a few people suggest that Zef would not be blocked if he knew what he was doing. This is true for the reason that once you see an error and know how to fix it, you will know what to do in the future. But it misses the point about what people new to the framework would feel when they use it. If a tool or framework cannot attract new followers easily, it will remain a niche.

The biggest problem with many useful open source and commercial software development tools is precisely this. The creators assume that since the target audience is the programming community, they can get away with unfriendly user interfaces that would not be tolerated in any product meant for general audiences. Or to be accurate, they don’t actively assume this, they don’t even realize that this is an issue.

Here is the crux. Programmers, senior or junior, have limited time to experiment with new tools. They are already productive with the tools they know and so wish to see the same ease-of-use and speed in new tools that they would like to add to their repertoire. Programmers learn by downloading the tool, installing it and trying out a few examples. If they can get something to run and can tinker with it, 90% of the struggle is over. They can keep experimenting and becoming a master of the tool.

On the other hand, if the programmer, after downloading the tool, sees a meaningless error message and then has to spend an hour Googling the term and tracing the error, then they will ditch the tool. Sooner if the tool has a tendency to keep throwing block after block.

There is a condescending school of thought that suggests that good programmers should be able to overcome any hurdles and it is better that the tool is complex enough to only attract the best in the business and maintain a community of experts. This, of course, assumes that good programmers want to spend days learning a non user-friendly tool that has a small user base and more likely to fade out with that kind of philosophy.

What can be done about it? I think there is a business model in here somewhere for a company to create more user-friendly and integrated versions of products. Say, an installation that bundles different products (say Eclipse with JBoss Seam and mySQL), and has a central administrative interface to configure and trouble-shoot. Or an IDE add-in that analyzes the code for possible typos and provides alerts.

Maybe somebody should create a search/answer engine for errors and exceptions. When you land on the answer page, it will provide the different possible scenarios that could have caused the error message, along with their probabilities. It could list the steps that you could take to identify the error.

Comments (0)

By Krishna, November 15, 2009

Jon Skeet has a long post on how programmers fall prey to pretty nasty bugs because they aren’t aware of the details of what they are doing. And he offers the following thoughts:

First, try not to take on more complexity than you need. If you can absolutely guarantee that you won’t need to translate your app, it’ll make your life a lot easier. If you don’t need to deal with different time zones, you can rejoice. Of course, if you write a lot of code under a set of assumptions which then changes, you’re in trouble… but quite often you can take the “You ain’t gonna need it” approach.

Next, learn just enough about the problem space so that you know more than your application’s requirements. You don’t need to know everything about Unicode – but you need to be aware of which corner cases might affect your application. You don’t need to know everything about how denormal number representation, but you may well need to know how rounding should be applied in your reports. If your knowledge is just a bit bigger than the code you need to write, you should be able to be reasonably comfortable.

Pick the right platforms and libraries. Yes, there are some crummy frameworks around. There are also some good ones. What’s the canonical answer to almost any question about java.util.Calendar? Use Joda Time instead. There are similar libraries like ICU – written by genuine experts in these thorny areas. The difference a good library can make is absolutely enormous.

To add to this, I would say that it is very important to enroll in a computer science degree in college before embarking on a programming career. I know there are very good programmers who have learnt everything on their own. But for the general population, it is a good idea to be fully involved in 2-to-4 year degree that provides you some basics, such as what floating-point representation means. Of course, you still have to do the learning, but your physical presence in a classroom is a higher probability that you may learn something.

While recruiting new employees, I always take a look at their academic scores. Although a good academic record does not guarantee a good programmer, a bad record invariably points to a poor software developer, with very few exceptions. Apart from the obvious IQ reason, here are some of the ways why this is so.

1. Getting things done: All other things being equal, a person who pays attention to end results is more valuable. If a person has high IQ, but doesn’t translate that to results, it usually means that they don’t care about delivering results. They may like learning and tinkering, but they will not deliver.
2. Lack of in-depth knowledge: An exam is not the perfect way to measure knowledge and application of knowledge, but it is among the best systems we have. If someone scores a passing grade on an operating systems course, they are probably missing a lot of important information.
3. Problems with authority: Innovation and breaking rules are important, but you also need some level of conformance to the goals of the organization. Poor scorers are sometimes rebels. They don’t feel the need to impress anyone (parents, teachers, etc.) or sticking to schedules.
4. Lack of perseverance: Some people simply lack the determination to tackle tough subjects. They may do well in a controlled setting, but when faced with challenges, they may need a lot of attention.

An example of an exception may be that somebody had a medical or family problem that affected their grades. Or they had a temporary blip that they got over. As always, you have to consider the whole picture. But definitely, academics should be a big part of your hiring process.

Comments (1)

By Krishna, October 21, 2009

Rob Conery pointed out an interesting comment on his IoC post:

In this simplified example above you switched from 3 lines of easily understandable code to something that requires code in the global.asax, another couple classes, and an interface. The end result contains an extra line or two of code, but now the whole thing is “reusable” and can be unit tested. I happen to agree with Joel’s quote which you openly mocked… it *is* more convoluted. It *is* harder to read and grok. And this was an overly simple example… I’m sure it gets more convoluted with large projects.

I am going to ignore IoC for a minute and take this in a general context. Some junior programmers have a tendency to write lengthy code instead of splitting the code into different classes and methods. The code, in itself, is not bad. I am not talking about poor variable names, bad formatting, copy-and-paste or low level silliness. But it is structurally deficient in the sense that

1. Each method will have many lines of code doing different things. In other words, the method has multiple responsibilities.
2. The coding is algorithmic, i.e., although they are coding in an object-oriented language, the coding is very linear in terms of execution.

I used to have a different perspective about people who did this kind of coding, but over time, I have concluded that this has got to do with the (learnable) ability of programmers to deal with complex systems consisting of different building blocks.

Junior programmers need to see, feel and know the entire program. They feel lost and confused otherwise. This is only possible if the code is one place and it has a very linear structure. This is enough for simple programs. But more complex programs require more code.

Well, it happens that a tree-like structure of code is also easy to understand because it is a easy progression from a linear code structure. You start from the root (the main method), navigate linearly, traverse each branch (if you come upon one), re-trace your steps and keep going until you are done. If the tree structure is not deep, you don’t have to keep too many things in your head and the complexity is managed.

The tree-structure is achieved by moving chunks of code into different sub-routines. But here is where the problem starts. You don’t get a true tree structure because you can call different sub-routines from different parts of your program – almost like having a leaf shared by different branches. Now, this is not a problem when the methods are very simple, but when they start manipulating data, it starts getting complex again. Another problem is that in modern event-driven programming environments, there is no “root” of the program. The linearity has been broken. What you have is a graph that has many inter-connections (or dependencies). Once again, complexity rears its ugly head.

We have different techniques to manage this complexity. Object-oriented design (especially encapsulation), refactoring techniques and design patterns help us manage the increasing complexity of software applications. But some of the techniques seem counter-intuitive if you have never used them.

For example, a junior programmer can reduce some complexity in his code by isolating similar code and moving it into a method with parameters. This reduces the code and decreases the complexity. On the other hand, moving data and code into a new class seems to increase code. It seems to imply more code to understand and worry about.

But, of course, this is not true. The point is to move code into a place where it can be completely forgotten. You create the new class that can be tested on its own and then only worry about the code that interacts with it. To a large extent, we already do this by tapping into the framework classes and APIs.

I want to emphasize that this is a learnable skill. These are all well-documented techniques waiting for some investment of time and effort. As you learn them and use them more in your code, you will become familiar with how they work. Some of these are easier and/or more commonly used than others, so it may take a while to be an expert in them all. The point is to keep learning and keep becoming a better programmer.

Comments (2)

By Krishna, October 16, 2009

In short, no.

But why am I asking the question in the first place?

Well, much discussion in the technical blogs (such as the NOOP.NL Top 200) is centered around the idea about whether a mediocre programmer will land on a blog where somebody is talking about adopting a simpler approach to programming and then use that idea to stop improving himself and continue writing bad code.

It is a useless subject to argue about because bad programmers do not haunt technical blogs. This is how such a person works:

1. Come in at 9 am or whatever time you are supposed to come in.
2. Find out what task to do.
3. Is the task something that looks familiar? If so, go to Step 7.
4. Interrupt someone in the office. Do they know the answer? If so, go to Step 7.
5. Google for the answer. Is there anything there that works? If so, go to Step 7.
6. Complain to the project manager that the task cannot be done and get something that can be done.
7. Do the task.
8. Is it time to leave? If so, go to Step 11.
9. Is there any other task? If so, go to Step 3
10. Kill time until it is time to leave.
11. Leave.
12. Enjoy the rest of the day.

What they don’t do is spend time visiting technical websites or blogs unless they happen to be landing on them via Google. And those Google visits are only for the purpose of finding some code that works. And issues like intellectual property rights be thrown to the winds.

So let us be clear about the audience when we are arguing about technical debt. We are having an argument among people who know how to write good code and how to test it properly. Some of them use a few more tools and a little more process than the rest, who are constrained either by their lack of knowledge, awareness or business situation to imitate them. No one among this crowd is writing bad code, as in copy-and-paste coding or bad variable names.

Therefore what we are really discussing about and what needs to be answered by people are:

1. You are a good developer who gets things done without Process X or Tool Y.
2. How much beneficial for you would it be to use X or Y?
3. How much time, effort and money do you need to invest for using X or Y to get started in and then be proficient?
4. What is the return on investment if you use X or Y?
5. Let’s understand if X or Y makes sense in your situation, including timelines, budgets, technical environment.

There are literally thousands of programming tools, techniques and processes out there, all claiming to increase productivity. So whatever the “best thing” you are promoting is, you have to justify it in these terms to the good programmers. And someone who cannot justify that is simply selling snake oil.

As for the other programmers, they are out there enjoying the day and definitely not dreaming in code.

Comments (0)

By Krishna, October 10, 2009

The title comes from the field of literature and art where writers (and movie directors) are rebuked for using narration (“he was sad”) instead of using actions and thoughts of a character to illustrate a situation.

Much of the recent debate over unit tests and Inversion of Control has been the meta discussion: “Unit tests are hard” versus “No, they are not” and so on. Which is why Rob Conery’s post on IoC and its sequel are worth reading. Well, at least for the .NET audience. Honorable mention also goes to Justin Etheredge for a similar (but less detailed) article.

I would note a few points. First is that not all IDEs and IoC containers are created equal. Those who are working outside the .NET space and are not using commercial products can sometimes find the going tough. Maybe this is just my experience with open source tools, but it does take a non-trivial amount of time to set up your environment properly and then work with it easily.

This should not deter someone who wants to get it done. But if someone is exploring how it is working, there is a barrier for such beginners and can sour them on the experience. My advice to the open source community is to come up with installation packages that can make it easy for such programmers to get started with these tools easily. Greater usability will mean proliferation of best practices in the general programming community.

Second, there is a virtuous cycle in place with these programming practices. Someone using TDD has a greater chance of using IoC. And that same person is more likely to learn and use design patterns where applicable. So you perhaps only have to give a small push to a programmer to get them rolling on the way to adopt these best practices. Start them with unit tests and soon they will be on to bigger things.

Finally, while we have good tools, there is still scope for improvement. A common complaint about TDD are tests that achieve greater coverage, but are either meaningless or boiler-plate stuff. There can be more intelligent unit testing tools that generate generic tests, allow the programmer to override them where necessary and spend more time on writing tests for more complex code. We are getting there, especially in the .NET space, but more of that would be better.

Comments (4)

By Krishna, October 9, 2009

There are a lot of them, but I keep coming across one all the time. Here is an example (emphasis mine):

Brad Fitzpatrick, born in 1980, started to learn programming at the age of 5. In high school he went on to create a voting booth script called FreeVote, which he says earned him as much as 27 cent per click on banner ads back then (making for 25, 27 grand per month).

I touched my first computer (for playing chess) at the age of 14. I touched my first mouse (at a science fair) at the age of 19. I wrote my first C program at the age of 21. I have done a lot of programming since then, but the 16-year difference is a huge gap.

The reason is that my family and I didn’t have the money to buy a computer, nor did the schools and under-graduate colleges I studied have them for programming purposes. So I had to wait till my graduate studies. Those institutions have the right facilities today, but back in the 1980’s and 1990’s, India was just emerging from the lost years of the License Raj. The cohort I belong to share the same experience. We probably read a lot more books than a similar American demographic, but programming, not so much. (I remember reading a book on BASIC, but no computer to type it on.)

Time equals knowledge. A vast majority of the senior Indian programmers had their first experience with software development in college. While looking at reasons for the relative low proportion of software products coming out from India, this must be kept in mind. The Indian developers did not know enough programming to start a company or write great software during the early years of their youth, which are usually the most productive.

This is rapidly changing now. With the tremendous improvement in living standards over the past two decades, millions of Indian children are being raised in families that have “the” hardware! The gap in software innovation and entrepreneurship will surely decrease as these children grow up to become software engineers.

Comments (0)

By Krishna, October 8, 2009

Daniel Auger defines a new term:

The Legacy Programmer Boss is the manager who had a successful programming career in the past but sees many modern concepts as language baubles, academics, and anti-patterns because they are out of the loop. The fact that they once had a high degree of expertise gives them confidence in making mis-judgements.

This is a problem for every programmer who gets promoted to a role where they have to spend some portion of their time managing other programmers. Usually, the point is that the senior programmers is more experienced and knowledgeable than the other programmers. And so, it is a better use of their time to take on higher-level tasks (architecture, design) and provide guidance to the others.

So far, so good. But as time goes by, the other programmers also gain expertise. And they spend more time exploring and experimenting than the senior programmer. Partly because the latter has to be focused and specialized (though not always). The junior programmers also tend to be more receptive of newer ideas and possibilities.

When the senior programmer is faced with choices involving newer technologies, they find it difficult to understand its value. First, because they don’t know anything about them. Second, they have already finished successful projects without using them.

To take an extreme example, take a programmer back in the good old days when they used tape to record programs. She did not have the luxury of an IDE, multiple compile-run cycles, testing and so on. She had to get the program right on the first try because it would be hours or days before she could run it again. So, she would wonder why modern programmers need so many sophisticated tools when they could design the code before they start writing a line?

Or take an experienced C/C++ programmer wondering what the big deal is with programmers complaining about pointers, memory management and multiple inheritance. Or a Java programmer amazed at why some developers are obsessed with syntactic sugar. And on and on – take your pick in newer languages, tools, methodologies, components, etc.

Everyone is prone to this syndrome. Something worked for you in the past. So without even thinking, you tend to dismiss newer developments. The only antidote is to keep up with the new stuff through software communities (real and virtual), reading books and blogs and so on. More variety and more exposure will reduce incidences of acting like a legacy programmer boss.

Comments (0)

By Krishna, September 3, 2009

Two somewhat conflicting needs of programmers:

1. Write as little code as possible.
2. Reduce coupling as much as possible.

I wonder if they can ever be achieved together entirely, but one thing that seems to be happening is that Item (2) is getting done with more and more functionality getting into the software environment (operating system, virtual machine, web framework). And so Item (1), the code that the programmer writes is shrinking.

At the same time, because we have more wants and needs, the functionality we demand increases. So you still end up writing a lot of code. Which is perhaps a good thing in one sense, because if the amount of programming was negligible, why would you need programmers?

I like the attitude of some programmers where they strive to write really concise code, but I wonder what would happen if they could shrink their codebase to one line of code, and thereby put themselves out of work.

Comments (0)

By Krishna, June 22, 2009

I am an advocate of programmers starting their own blogs so that they can share their thoughts on programming and software development. But this is not necessarily a natural thing to do because writing is different from programming. The natural thing for a programmer to do is to write programs (duh!). So when you interview a programmer, a good judgment of whether they are good programmers is to ask them what kind of programming they do outside work. Do they have a hobby project they are working on? Are they contributing to some group project (open source or otherwise) online? If they also have a blog, that is a plus because it shows a passion for communicating with others, but it cannot be a filter.

On the other hand, when somebody is paid a salary for writing, i.e., they produce documentation or do some sort of technical writing, it just feels wrong when they do not have a blog or other outlet for writing. A person who likes writing will do it even if they are not being paid, because they have the need to put words to paper or the screen. So the equivalent interview question for such a person would be, what kind of writing do you do outside work? It doesn’t have to be technical stuff. Maybe they are writing a poem or a children’s story. But whatever it is, it demonstrates how much they love writing.

Similarly, a graphics designer without a personal website seems like an oxymoron. Does the person do the work only if they are paid to do it? Are they not interested in exploring design layouts, HTML, CSS and all the interesting stuff in the graphics world? Also importantly, how confident are they in showing the world what they have got in design skills?

So there you have it: The single most important question you can ask in an interview is about the natural thing for a professional to do outside their working hours? If they don’t have anything remotely connected to their profession, it is an indication that they don’t value the profession so much.

Obviously, there are exceptions. If a person is working in a sweatshop and only going home to sleep, or they don’t have the resources or are forbidden by law to tinker outside the workplace, that is fine. But in the normal course of events, you would always want to look at people who maintain their interest and use their time outside work.