Basically, the Joel Test has the following 12 questions you need to answer in a Yes/No.

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

Here I try to apply the test to our software team and figure out how well we fare.

1. Do you use source control?

Yes. We do use CVS (Concurrent Versions System) for source control. Since we use Eclipse as an IDE, a CVS client is already available with it.

Source control is the most important tool used during software development because:

1. We always got a backup of a working copy of your software. So if one of the developers accidentally messes the code, we can always revert back to the previous version.
2. Source code tools have a way to branch out your code. So you can maintain separate builds for different clients or products.

Of course there are also a few inconveniences when using source control. Source control enables two or more developers to work on the same piece of code (say a same file). So when it’s time to check in the code into the source control repository, a merging needs to be done. Source control tools are smart enough to merge changes that are independent but sometimes a manual merge is required. Also your local copy of the code will need to be updated everyday to be in sync with the repository.

There is no reason not to use a source control especially with so many good tools like CVS, SVN, and Git freely available.

2. Can you make a build in one step?

No. We can made a build in few steps though. The reason why we can’t do this is because there are a few dependencies like changing configuration files on servers. For production, it could also mean getting signed keys before you can actually make a build.

My view is that as long as we have a good process established for making builds, then it is not a problem to make builds in more than one step. Of course, it should not be something like a 100 steps but 5-10 steps would be just fine.

3. Do you make daily builds?

No. We do make builds every few days but not every day. I see no reason why this cannot be done everyday except the fact that our code base does not tend to be updated every day. We make builds only when enough tasks/defects have been resolved to warrant a build.

We do have a system that runs every few days just to check if the build is broken or any other issues were introduced in the build. But it does not create an official test build.

I think our team is quite small and it rarely happens that someone checks in code that breaks the entire build. It’s enforced strictly that developers compile the code in all possible configurations before they check in. IDEs like Eclipse make it relatively easy to ensure that you check in all the affected files and don’t skip any of them.

4. Do you have a bug database?

Yes. We use JIRA for bug tracking and find it very good. It has all the features like bug tracking for various projects, mentioning bug types, assigning priorities to bugs, assigning bugs to the concerned developers and a commenting system.

Bug tracking is essential to software development to ensure communication between developers and testers. It makes sure that all defects found by testers have been recorded for easy tracking. Systems like JIRA can also be used for task management along with bug tracking.

5. Do you fix bugs before writing new code?

Yes. Once an official test release is made and testers start detecting bugs, developers immediately start working on those bugs. So working on existing bugs is given more priority to working on new features.

However we work with Scrum as a method of the Agile framework. So work is basically divided into Sprints. Each sprint has a particular scope of work that needs to be completed within a period of say 2 weeks. This holds for the entire team of developers and testers. So it could happen that only basic testing is done during sprints and an actual complete system test is only done after completion of most of the development tasks. What this means is that it could be weeks before some of the defects are detected that could have been detected earlier simply because the priority of extensive system testing is lowered to the priority of testing the new features.

6. Do you have an up-to-date schedule?

Yes. Scrum helps us schedule the tasks that are planned for the next couple of weeks. The tasks are based on priority of the customer and tasks which are not important are cut out of the schedule.

It could happen that the customer changes his mind in time so that the priorities get changed. This causes a bit of mayhem on the earlier planned schedule. Maybe something to work on is to perform scope reduction to recalculate the priorities of the tasks, remove the unwanted tasks and again perform a re-estimation to inform the client what can and cannot be done in the remaining time.

7. Do you have a spec?

Yes. Though Scrum does not actually need requirements and design specifications. The emphasis is to start working on code as early as possible.

But since we are an onsite-offshore model, we require to have the approved requirements specifications from the customer. It could be that only some of the requirements are approved and the remaining will be done as time progresses. Same is the case with the design proposal. It could take some time for the design proposal to get approved so there is no choice but to start with the coding. As Joel mentions, this is a risk (that Scrum actually incorporates) that the requirements could change causing an expensive rework.

Till the requirements and design are finalized we start working on prototypes that we can later reuse. The advantage of this method is that we tend to know design issues or coding issues as soon as the prototyping begins. Also if there is not much change in the requirements, we can reuse parts of the prototype for the final implementation thus saving up time.

8. Do programmers have quiet working conditions?

No. Most organizations in India love to follow the cubicle way of working. Developers and testers are surrounded by each other. So noise and distractions are unavoidable.

Scrum actually promotes that the team sits in proximity to ensure that problems can be immediately communicated and resolved. Developers and testers tend to put their minds in a state of total concentration when working. So too many interruptions and distractions can be responsible for decreasing the productivity of employees. Unfortunately, the cubicle mentality is deeply embedded and there is not much that can be done to change this way of working.

9. Do you use the best tools money can buy?

Yes. Most of the development tools have been provided by our customer and they are quite good. We do tend to have issues when it comes to using the latest in computer hardware. Fortunately we have just upgraded to decent computing platforms recently.

Software organizations require that computing resources always stay upgraded to the latest technology. This is probably one of the cheapest and best ways to improve the productivity of employees especially developers. Time for activities such as compilation and debugging is significantly reduced by upgrading to the latest hardware.

10. Do you have testers?

Yes. Testers are an integral part of our software development team. They are our line of defence against defects that are missed by developers. We also have some level of automated testing for some of the tasks.

Though most bugs should ideally be found out by developers, many times it so happens that developers work on isolated features that finally get combined into the system. System tests and regressions tests are very important to find out defects that could easily pop up in production. Such testing is the forte of testers who can hit the system from all possible angles.

Of course, testers can only do the black box testing. But its possible that some parts of code are not being hit in such black box testing. Then you could have developers act like testers to find out such defects. Or you could have testers who could also think like developers and perform some white box testing.

Some of the mundane testing that needs to be done after every build could be automated by using an automated test system. This helps to detect bugs early and also frees the testers to work on finding out more ways of breaking the system.

11. Do new candidates write code during their interview?

No. This is something that we need to work on. We do ask the candidates questions to check their existing skills with a programming language and their logical ability. We do tell them to write some code but not much.

It’s quite difficult to know the level of a developer just in an interview. Making a candidate write code is a good way to know how much he/she has been in the trenches. However equally important in a developer is the ability to know how to approach solving a problem. The quality of a good developer is to search and probe ways to solve the problem before interruption another developer. Equally important is to know how passionate a developer is in working with you. It often happens that many developers have no passion for their work. Such developers end up doing work that they are assigned and nothing more. Finding developers who are constantly trying to improve themselves is a difficult task.

12. Do you do hallway usability testing?

No. Because this is one of the projects that is dependent on a domain. So an average user will have to ask 100s of questions before he becomes aware of what the system is about and what all he is supposed to do.

I think this entirely depends on the type of system that is being developed. If you are developing a web site or a online payment system, it is relatively easy to have random people perform the hallway usability testing. But if you are working on systems like a micro-controller for traffic signals or a device driver for USB support, such testing just falls out of scope.

So we scored 7 out of 12 on the Joel Test. However points 2, 3 and 12 don’t quite apply to our team. So the final score could be 7 out of 9 which is pretty decent. We can’t do much about getting quiet working conditions except maybe using noise cancelling headphones. We can surely work on the point of asking new candidates to write code during their interview.

Related Posts:

• Programming Is About Doing The Job Right
• Today's Read: Four Ways To A Practical Code Review
• Don't Be A Hotshot Programmer, Be A Boring Programmer
• How To Avoid Bugs By Not Writing Code (At-least Not Too Much)
• Painless Software Development Part 4

Often times, we programmers have to sacrifice our urge to innovate by working on the so called “boring” programming tasks. This happens because as professionals we need to work on and deliver software as expected by our employers. The world needs many of the so called information systems such as Time Management, Appraisal Systems, Accounting Systems, etc. Developing these systems seems like a mundane repetitive task that involves updating a database and providing users an organized view of the data. And we all want to work on the cool applications like the iPhone or Google Maps. It comes across as working on something that users take for granted versus something that makes the users go “Wow”.

So as a programmer should we be satisfied with our jobs because it helps pay the bills or should we try to find a job that will satisfy us by allowing us to keep challenging ourselves? The answer is provided by several comments in the excellent article, Programming Sucks! Or At Least, It Ought To.

At the end of the day, the best programmers are not the ones who create the most beautifully-elegant, exceedingly-innovative code. The true rockstars can deliver software before deadlines, under budget, and that does exactly what the business needs. And those are the type we should all strive to be.

As the wise programmers mention, that if we find writing software sucks then we probably have wrong programming values. True programming is about writing software that solves problems for people. And the true satisfaction a programming professional should strive for is in doing a good job solving those problems.

Of course, we need to be innovative and challenge ourselves for motivation and improvement as a programmer. It is ourselves who need to take responsibility for our improvement as a programmer instead of restricting our learning to programming at our workplace. Working on projects that interest us and challenge us is the best way for improvement. With many open source projects available today, we can surely find something we could contribute to.

It may also happen that we grow out of the technology or the domain we are working on. If you are like me, you could be one of the people who like to move out of a project once we feel that we have learnt and contributed as much as we could. There is nothing wrong with the project and it may also be the so called innovative work but it just may be the time to switch to some other work perhaps to keep ourselves motivated.

Related Posts:

• Best books for beginning programmers
• Did We Pass On The Joel Test?
• The Ten Commandments for C++ Programmers
• Today's Read: Four Ways To A Practical Code Review
• The History Of Carriage Return Line Feed

It’s been around 7 years that I have worked with software projects that use the C programming language. I’ve been contemplating learning a new programming language for some time now.  So what should be the language of choice for me or rather for a developer with a background in C programming?

Should I go for the C++ language that has it’s roots in C and will be much easier for me to learn? Or according to the TIOBE index should I consider it not worth learning and switch to the ever popular Java language? Or maybe I should give a try to the Python, the supposedly most popular programming language being used by Google, Yahoo and the likes?

Let’s see if I can try to choose based on the factors that developers consider in choosing a programming language. The competitors for my choice are C++, Java, Python and C#.

1. Simplicity

By simplicity, I gauge how simple it is to know about the programming language. How easy it is to just read a few tutorials and get a basic understanding of the language. What are the features of the language and how many times do I have to read through them to understand about them.

I have read a bit of Python and it surely seems to top the list in terms of simplicity. And this seems like the view of many developers. Java seems to be the next in the list in terms of simplicity. I am not quite sure about C# but I suppose it will be much simpler than trying to learn C++. So for me C# ranks above C++ in terms of simplicity if you are a fresh programmer trying to learn a programming language. But since I have a background in C, C++ may not cause me that steep of a learning curve.

2. Availability of an easy to use Integrated Development Environment

Integrated Development Environments (IDE) seem to be the first choice of developers in selecting a programming language. Vim and emacs fans may disagree on this but like many developers I consider that my time should be spend on creating cool stuff rather than trying to figure out the key combination for opening multiple windows in emacs.

All the contenders i.e C++, Java, Python and C# seem to have some good IDE available. C++ can use Visual Studio or Eclipse, Java and Python can use Eclipse as well, C# can use Visual Studio. Both Visual Studio and Eclipse are excellent and proven IDEs.

3. Good documentation and support

Documentation includes the documentation provided by the programming language creators, the amount of easily accessible tutorials on the Internet and the number of books that have been published related to the subject. Support is how good the creators are in releasing new versions with critical bug fixes and feature enhancements. In short, how actively the development of the programming language is being maintained.

All the programming languages i.e C++, Java, Python and C# seem to have some pretty good documentation and lots of tutorials on the Internet. There is also no dearth of the amount of books that have been published for these programming languages. Maybe there are more books for C++, Java and C# than for Python but I may be wrong and maybe it’s because Python has not yet caught up the mainstream application development at least in India.

4. Popularity

By popularity, I intend to probe the popularity among the developers as well as the popularity in the job market.

Java has to be the one of the most popular programming languages among the developers. While I do not have any statistics for this claim, I feel that this is true considering the amount of developers who work with Java not just in the organization that I work for but also many others. Next in popularity seems to be C# since Microsoft does a good job in promoting their software development tools among the developer community. C++ seems to be hanging there in the TIOBE Index but I have mixed reactions about it’s popularity among developers. Python right now is not quite popular among Indian developers and maybe it is related to the second point about the job market.

There are a plethora of jobs available which require Java and C# skills. There are also jobs available that require C++ skills. But not many jobs in India require Python programming skills.

Conclusion

So after this personal analysis of the currently popular programming languages, which language is it that I have decided to learn? Actually I settled on more than one language. I found that it is relatively easy for me to start some object oriented programming with C++ considering my C background. Once I have some level of understanding, I will move on to learn Java because it seems to be somewhat similar to C++.

Related Posts:

• No Related Posts

package main
import "os"
import "fmt"
func myfunc() int{
   filename := "error.txt"
   file, err := os.Open(filename, os.O_RDONLY, 0)  //the err
   if err != nil{
      fmt.Println(err.String())
      return -1
   }
   var b []byte
   file.Read(b)
   return 0
}
func main(){
   myfunc()
}

err is of type os.PathError that provides a String() function that generates an informative string.
i.e. err.String() will return the string,

open error.txt: no such file or directory

Panic
Sometimes the error is unrecoverable and the program simply cannot continue. Go provides a built-in function panic() that creates a run-time error that stops the program.

package main
import "os"
func myfunc() int{
   filename := "error.txt"
   file, err := os.Open(filename, os.O_RDONLY, 0)
   if err != nil{
      panic(err.String())
   }
   var b []byte
   file.Read(b)
   return 0
}
func main(){
   myfunc()
}

Output as a result of the panic is as shown below. Seen is the string passed as argument into panic. Also seen is the stack as it unwinds due to the panic.

panic: open error.txt: no such file or directory
panic PC=0xc4b044
runtime.panic+0xa9 /home/kevin/go/src/pkg/runtime/proc.c:1020
	runtime.panic(0x0, 0xc4b074)
main.myfunc+0xa0 /home/kevin/programs/error.go:13
	main.myfunc(0x8061b98, 0xc471f0)
main.main+0x1f /home/kevin/programs/error.go:20
	main.main()
mainstart+0xf /home/kevin/go/src/pkg/runtime/386/asm.s:83
	mainstart()
goexit /home/kevin/go/src/pkg/runtime/proc.c:145
	goexit()

Recover
Panic can be called explicitly in our program or it may be called implicitly due to run-time errors such as indexing an array out of bounds or failing a type assertion. It immediately stops execution of the current function and begins unwinding the stack of the goroutine, running any deferred functions along the way. If that unwinding reaches the top of the goroutine’s stack, the program dies.

The built-in function recover can be used to regain control of the goroutine and resume normal execution. A call to recover stops the unwinding and returns the argument passed to panic. Because the only code that runs while unwinding is inside deferred functions, recover is only useful inside deferred functions.

Recover can help us simplify error handling in complex software and to exit a program cleanly.

package main
import "fmt"
import "os"
func myfunc() int{
   filename := "error.txt"
   file, err := os.Open(filename, os.O_RDONLY, 0)
   if err != nil{
      panic(err.String())
   }
   var b []byte
   file.Read(b)
   return 0
}
func main(){
   defer func() {
      if p := recover(); p != nil {
         fmt.Println("myfunc failed:", p)
      }
   }()
   myfunc()
}

In this example, if there is a panic in myfunc(), the result will be logged and the goroutine will exit cleanly without disturbing the others. There’s no need to do anything else in the deferred closure; calling recover handles the condition completely.

Ouput as a result of the panic is as shown below

myfunc failed: open error.txt: no such file or directory

Related Posts:

• How To Achieve Concurrency In Google Go
• How To Use Inheritance In Google Go
• How To Use Interfaces In Google Go
• How To Dynamically Allocate Memory In Google Go
• How To Use Control Structures In Google Go

Advantages of goroutines:
1) Lightweight, costing little more than allocation of stack space.
2) Simpler than thread management.

Prefix a function or method call with the go keyword to run the call in a new goroutine.

go list.Sort()  // run list.Sort in parallel; don't wait for it.

A function literal can be handy in a goroutine invocation.

func Announce(message string, delay int64) {
    go func() {
        time.Sleep(delay)
        fmt.Println(message)
    }()  // Note the parentheses - must call the function.
}

Channels
Channels are used to communicate between goroutines.

Like maps, channels are a reference type and are allocated with make. If an optional integer parameter is provided, it sets the buffer size for the channel. The default is zero, for an unbuffered or synchronous channel.

ci := make(chan int)            // unbuffered channel of integers
cj := make(chan int, 0)         // unbuffered channel of integers
cs := make(chan *os.File, 100)  // buffered channel of pointers to Files

Any value may be sent over a channel. To send a value on a channel, use <- as a binary operator. To receive a value on a channel, use <- as a unary operator. When calling functions, channels are passed by reference.

package main
import "fmt"
func thread(ch chan int){
   fmt.Println("Thread")
   ch <- 1                 //send the signal on the channel
}
func main(){
   ch := make(chan int)
   go thread(ch)           //starts a goroutine
   <-ch                    //blocks till goroutine sends the signal
   fmt.Println("Main")
}

Receivers always block until there is data to receive.

Mutex
We can use channels to achieve the functionality of mutex as below. Thanks to MizardX for the example.

package main
var global int = 0
var c = make(chan int, 1)
func thread1(){
    <-c         // Grab the ticket
    global = 1
    c <- 1      // Give it back when were done
}
func thread2(){
    <-c         // Grab the ticket
    global = 2
    c <- 1     // Give it back when were done
}
func main() {
   c <- 1 // Put the initial value into the channel
   go thread1()
   go thread2()
}

Alternatively, mutex are available in Google Go in the sync package. It contains the Lock() and Unlock() functions to use mutex as shown below.

package main
import "sync"
var global int = 0
var m sync.Mutex
func thread1(){
   m.Lock()
   global = 1
   m.Unlock()
}
func thread2(){
   m.Lock()
   global = 2
   m.Unlock()
}
func main(){
   go thread1()
   go thread2()
}

A more idiomatic way to use a sync.Mutex would be in an struct as shown below. (Thanks to j for providing a better program).

package main
import "sync"
type Global struct {
   Value int
   sync.Mutex
}
var g Global
func thread1(){
   g.Lock()
   g.Value = 1
   g.Unlock()}
func thread2(){
   g.Lock()
   g.Value = 2
   g.Unlock()
}
func main(){
   go thread1()
   go thread2()
}

Useful links:
Effective Go
Go for C++ Programmers
The Go Memory Model

Related Posts:

• How To Handle Errors In Google Go
• How To Use Inheritance In Google Go
• How To Use Interfaces In Google Go
• How To Dynamically Allocate Memory In Google Go
• How To Use Control Structures In Google Go