While perhaps easier to get into than it should be, software development is a difficult and demanding field to be successful in over a long period of time. A lot is asked of developers as we are often given nebulous business requirements and asked to make a functioning system. In my experience here are six traits all successful developers seem to poses.

1.Pupil

For a developer to be successful over any period of time a continued commitment to learning is absolutely vital. The field is too large, too quickly changing, and too in depth for any developer to ever "know it all." Luckily there are a lot of resources a developer can use to learn; books, co-workers, classes, blogs, among many others.

In my personal experience I have found one of the best resources for learning have been my co-workers. Books, classes, and most online resources are largely impersonal and geared toward large audiences, they simply cannot provide the help that a co-worker familiar with your issue or habits can provide. Which leads me to my next important trait...

2.Mentor

As a developer understands he does not know it all, he will also realize that this same quality exists in all developers. It is important for every developer to act up this knowledge and be willing to help other developers learn. It is particularly important when dealing with junior developers, those fresh out of school. Often these developers know just enough to be dangerous and do not realize this yet, so it is important to teach junior developers good practices, to prevent them from picking up (and potentially propagating) bad practices.

There is a responsibility in being a mentor and that is ensuring the knowledge being passed on is good. I have taken this responsibility for granted in the past, at the time I didn't understand the importance of getters and setters and I irresponsibly suggested not to use getter setters. Mentors who take this responsibility seriously however end up helping themselves just as much they help others. In order to understand why a practice is good a deep understanding is often required and understanding the fundamentals of a concept in my experience offers the most benefit.

3.Flexible

As alluded to under the pupil trait, software development is a rapidly changing discipline. Developers must constantly be looking at and reviewing their practices to see where improvements can be made. Much of the time the improvements are small and incremental, but occasionally entire upheavals must take place. A developer must be willing to accept that one day practices and technologies once relied upon have become obsolete and entirely new technologies and practices must be learned. Clearly this isn't an endorsement to blindly jump on every new trend, but to be aware of how the industry is evolving, familiar with the emerging technologies and practices, and willing to learn them should your job or the industry demand it.

4. Tester

Testing isn't simply a responsibility of the QA team. It is a core responsibility of a software developer. Testing isn't just part of the development process, but even the design process, from both a business and system perspective. The system perspective is somewhat obvious, but testing can also play a role in change business requirements as well; scenarios could be discovered that were not previously accounted for, or a technology may be found to be inadequate to meet business needs.

Testing, specifically unit testing, is also an important part of writing quality and maintainable code. In the same way a structural engineer writes mathematical models to test his design and eventually creates scale models, a software developer writes unit tests to test his code. Unit tests give a developer instant feedback on rather the changes made broke the system, or fixed an issue. Just like it is a responsibility of a mentor to pass on good knowledge it is the responsibility of developers to write good tests. Good unit tests replicate real world scenarios as well as hit fringe scenarios and negative scenarios. Obviously such a task would be extremely laborious to write for an entire system, so it is important for developers to recognize when this practice must be applied.

5. Farmer

Just as a crop is a farmer's livelihood code is a developer's. A lot goes into growing crops, a farmer must; pick good seeds, ensure the fields are fertile, and be ever vigilant against pests. Similarly it is every developer's responsibility to; ensure the code he adds to is of good quality, ensure there are ways of monitoring it's continued quality, and remove bad code when found.

6. Reporter

Every so once in a while a picture comes along to perfectly describe a point. Few things are more infuriating to a developer than to be told there is a problem and given no additional information. It considerably increases the time turnaround time to fixing an issue (if one actually exists) as a developer must track down what he thinks is the problem.

This issue isn't just relegated to when a problem arises or just non-developers (which is why this trait is included). As a company grows its developers become increasingly specialized and responsible for individual systems within a collective whole. Before asking a question a developer should read up on a system's documentation (a lot of times a question need not be asked), good questions lead to good answers and ultimately a lot less frustration on both sides. Conversely a developer should also provide good documentation on the system(s) he is responsible for.

So there are six traits every successful developer should have. If you have suggestions for traits I should add or disagree with the ones I listed leave a comment.

Technorati Tags: Best practices

Last week I published an article on test driven development. One person who read my article (briefly) suggested I did not know that unit tests shouldn't talk to their data source. I plan on covering how to mock JDBC connections later this week, however I wanted to do some research to see if what my critic says is an industry standard or a philosophical choice.

Surprisingly there seems to be relatively little information on this subject, or I have been incapable of finding information. From what I have gathered though, the theory that data sources should be mocked is sound, but its may not always be practical to implement it. Below is two reasons why data source connections should be mocked and three reasons why they should not.

Why you should mock connections

Speed – Talking to a data source is one the primary operations that slows an application's performance. Most data sources require some sort of network connection and retrieving data is often a processor intensive task. Obviously performing these tasks take time. Unit tests are most useful when they are run automatically and frequently to ensure changes being made are not breaking the application. Unit tests that are run automatically should be somewhat speedy, by mocking a data source connection, this can reduce considerably the amount of time it takes to run unit tests.

Remove the reliance on the data source logic – Unit tests should be testing relatively small parts of code, individual methods and/or small collections of methods. By connecting to a data source you are depending upon the logic of not only how you are connecting, but how the data source operates. This goes beyond the scope of what a unit test should be testing.

Why you shouldn't mock connections

It's time consuming – Writing mocks can be a quite laborious task. I often avoid writing mocks like the plague, because even relatively simple mocks can require a considerable amount of time to get running and running correctly. Even my very simple example of running a single query against a five column table took several hours to setup. Granted this was my first time creating a JDBC mock and future mocks would be easier and quicker to write, but it would still take longer than simply connecting to my database.

It's ugly – It takes a lot of typing to get even relatively simple mocks working. A lot of the rules that apply to how real business code should be written need not be followed when writing unit tests, that said looking at the code of a unit test shouldn't make your eyes bleed. Unit tests that cannot be easily maintained often become ignored when they break and broken unit test have no value (if ignored).

It's not real – Mocks don't really care what you put into or take out of them. Real data sources are often not so forgiving. If I misspelled a column or table name in a query, a mock would not pick up on this (you can verify the sql statements run, but again that could be misspelled), where as a real database would. By actually connecting to the real data source you can be more confident that the application will perform its intended tasks.

Why you should use your head

Even within the same project there will be instances where mocking a connection to a data source is the right choice and instances when you should actually connect to a real data source. In the early stages of a project using mocks can be more practical as the structure of the data source is more abstract and subject to change. Rewriting a mock is often quicker and easier than restructuring a data source. However as a project matures and the unit tests become more complex, connecting to the real data source may be more practical as it is not only (more) well defined, but writing the mocks begins to require more time. As with all practices, you need decide which one is best to follow (or not) based upon your requirements and restrictions. Though I think it is worth noting standards are standards for a reason. Feel free to weigh in with your own thoughts on the subject.

Additional reading:
http://www.javaranch.com/journal/2003/12/UnitTestingDatabaseCode.html
http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html

Technorati Tags: Best practices, Mock, Programming, Testing, Unit testing

In my recent article, 8 signs your code sucks, one of my signs of bad code is: “You need to use comments to explain the code.” I have since taken a lot of flak for suggesting this and I want to clarify my point and why I am not backing down.

Not javadoc - I am NOT referring to Javadoc or its equivalents in other languages. I absolutely do agree that a method or class should have accompanying documentation at its declaration stating its purpose and its inputs and/or outputs.

Comments are not bad, the code is – I'm not suggesting to forgo the use of comments, but that they are only band-aids. When you don't have time to properly write a piece of code; do it the “messy” way, write a comment and give it a TODO as a reminder to go back and fix it later.

Comments make code accessible - Code should not be written to the level of the dumbest developer, the dumbest developer should be brought to the level of the code (though I want to reiterate good code should be easily readable). If a developer is unwilling or unable to meet or at least understand the rest of the team's coding standards, then questions should be asked rather you want that developer to understand the code at all.

They are more like guidelines – When it comes to design patterns there are no rules. From day one we are taught goto statements are evil and should never be used, but there is even a time and place for them. There may be rare occasions when you have to write a comment to explain a piece of code, just like you may need to use a goto to simplify the code, but both occasions are rare and when encountered in code should be scrutinized.

Technorati Tags: Best practices, Programming

As a wide eyed junior developer when I first began working on large projects I simply accepted that it is difficult to fix bugs or find where an action is being executed. If only I knew then what I know now, I would had saved myself hours of frustration. The first step to writing good code is accepting the code you write (or work on) is crap, but sometimes you need to know what to look for. Here are some signs that your code sucks.

A method is larger than the screen – A method should only perform one specific task. A method should not contain the logic code to determine if the username field contains data, is valid, and that user exists. If a method is too large to fit within a single screen, that is a (very) good sign it is doing too much.

You are reusing variables – Unless you are working on embedded devices, memory is cheap. Don't be a memory scrooge and knee cap code maintainability, which in nearly all instances trumps performance, by reusing the same variable for multiple uses.

You are directly accessing the request/session – It not only makes writing unit tests (much) harder, but it is also difficult to know what data the application has access to. All data should be taken out of the session/request and stored in a bean. A bean, through its getters and setters, creates a “contract” of what data the application has access to, which greatly helps with code maintainability.

You need to use comments to explain the code – Code should be able to explain itself and should be in a format that is easily readable. If you find yourself needing to explain what your code is doing then you may want to look into rewriting that code.
EDIT: This is not referring to using comments (e.g. javadoc) to explain the purpose of a method/class and its inputs and outputs.

An exception's stack trace doesn't return the original problem -  You should never “eat” an exception, that is catch an exception, but not print its stack trace. How can a bug be fixed if you don't even know where the bug is occurring?

Your code is a mud ball – Just the name sounds ugly. A “mud ball” is when there is little separation between the layers or concerns of an application. Code should be modular allowing for ease of reusability and modifiability. Anything concerning the user interface happens in the view, program flow and usually data validation is the domain of the controller, handling business logic is the model's job, and only the model should be interacting with the data access layer.

It is hard to write a unit test – If you find a bug or write a new piece of code and it takes you more than a few minutes to write a unit test then that portion of code is handling too complex of a task.

The author is Billy Korando – Wait what?!

Add your own experiences or signs for dealing with sucky code.

UPDATE: There are differing opinions on my signs, since I am but a mere "grasshopper" I maybe wrong. Anyways check it out and make up your own mind.

Technorati Tags: Best practices, Programming

Integrated development environments make developing application fair easier. They highlight syntax, let you know if you have a compilation error, and allow you to step through your code among so many other things. Like all IDEs Eclipse has a bunch of little shortcuts and tools that can make your life a lot easier, I've compiled a list of several that I use on a daily basis:

1. Auto-complete – Eclipse has an auto-complete feature that can be accessed with ctrl + space. When clicked a small pop-up box is displayed with a list of context sensitive suggestions. If there is only one possibility then Eclipse completes it for you.

2. Quickly format your code – Code that is being heavily modified can quickly become an ugly sight. Without proper indention it can become extremely difficult to determine what is happening in code. Code can be quickly formatted using the shortcut: Ctrl + shift + F. You can even setup your own style rules by going to: Project>Preferences>Java Code Style>Formatter, check “enable project specific settings” edit the profile and then save it under a new name.

3. Get rid of unnecessary code – Heavily worked on projects that aren't maintained well can quickly build up a bunch of unnecessary imports, casts, among other common easily detectable coding mistakes. Quickly remove these mistakes by running a code clean up. Right click on your project folder>source>clean up. Like the code formatter you can also customize your code clean up.

4. Go to declaration – Want to know where that method, variable, or class is declared? This can easily be done by holding down ctrl and then clicking on the reference.

5. Find all references – If you need to find all the references for a method, variable, or class highlight the desired reference right click>reference and select the desired search scope.

6. Quickly select groups of characters – Need to delete an entire string, or everything within a method's argument declaration? Select the enclosing character (e.g. the “ or "(" respectively), this will select everything within the enclosing characters. This even works with the bodies of classes and methods. You can also select an entire line by triple clicking.

7. Rename all instances – If you need to rename a method, variable, or class you can rename ever instance by highlighting a reference and pressing alt + shift + r an box will highlight the reference and you can rename it. Upon pressing enter all instance will be renamed in your project.

8. Change a method signature – If you need to change any part of a methods signature; a methods name, its arguments, or return type, you can quickly make a change to all references of the method in the project by highlighting the method and pressing alt + shift + c a pop-up box will appear giving you options to change the method's signature.

9. Automatically generate getters and setters – Writing getters and setters is for suckers. After you write out all the members of a class right click anywhere in the code screen>source>generate getters and setters. Select the variables you want to have getters and setters made for.

10. Javadoc is a cinch – Eclipse makes writing Javadoc easy, just type “/**” and press eneter above a declaration. Eclipse automatically creates context sensitive Javadoc annotations (i.e. a methods parameters, or the author of a class). After that you only have to write out what the method actually does.

11. Run a unit test – To run a unit test highlight the unit test and press alt + shift + x followed by t. You can also run a unit test in the debugger by pressing alt + shift + d followed by t.

12. Comment out code – If you need to quickly comment out a chunk of code, highlight the corresponding lines and press ctrl + /, you can uncomment code the say way.

Chime in with your own Eclipse shortcuts.

Technorati Tags: Programming

If you like what I have to say, share it with others by using the "Share" button at the bottom of every post. This button includes links to all the popular social sites. Help get Turnleaf Design out the masses by submitting an article or up voting already submitted articles. Your help is much appreciated, thanks!

With the publication of the first part of my SVN primer I will begin two major series on my site that will occasionally intermingled. My first series is what I like to refer as “The Promised Land.” This project will cover how to setup up an ideal development environment. Subjects will include version control, Ant (build scripts), Ivy (dependency manager), software configuration management (SCM), automated unit testing, and bug tracking. I may add a few subjects as requested or if I find anything else I think might be relevant and interesting. The series is name “The Promised Land” because hopefully by following the advice in the articles a development team can focus only on developing and maintain its applications and not have to worry about any other hassles. I will put all the "Promised Land" articles under the "Promised Land" category.

The second series and one which I am becoming increasingly excited about is developing a project that will track the accuracy of weather forecasting (I mean it always seems like meteorologist are just guessing). Ok that alone may not sound interesting, but what I plan on doing is using this project as an example for many other important topics. Sometimes it is difficult to understand the usefulness of design principle or a tool without seeing it within the context of an actual project, I plan on addressing this short falling. I already have a huge subject plan lined up:

Design methodology/Best practices

MVC
Data access Layer
Framework - Spring
Separating layers; best practices
Methodizing
Usage of static
Interface/implementation
Generics - explanation
Exception vs error handling
where to validate

Development environment

Hudson
Ant
Ivy

Unit Testing

Test driven design & more advanced JUnit tutorial
DBUnit
JMock
Automated Unit testing

Other

XML
JSON
JSPs
Webservices
How to consume Soap/WSDS
How to create REST/WADL
IDE tips

As I get closer to launching this project, which should be next week, I will give more details on how it will work.

I'm really excited about both of these projects and I think both will be very helpful to both new and more experienced developers alike. If you have any questions let me know in the comments section.

Sometimes developers use programming jargon that new developers have a hard time comprehending. One term I frequently hear is “bean.” All a JavaBean is, is a class used to define the attributes of a entity; examples of commonly used beans would be person, customer, and employee. A JavaBean typically only contain private attributes and the getter and setter methods to access and set those attributes respectively. Here is a simple example of what a Java bean looks like:

public class Employee {
private String firstName;
private String lastName;
private int yearsExp;
private String title;
private double salary;

public String getFirstName() {
return firstName;
}

public void setFirstName(String firstName) {
this.firstName = firstName;
}

public String getLastName() {
return lastName;
}

public void setLastName(String lastName) {
this.lastName = lastName;
}

public int getYearsExp() {
return yearsExp;
}

public void setYearsExp(int yearsExp) {
this.yearsExp = yearsExp;
}

public String getTitle() {
return title;
}

public void setTitle(String title) {
this.title = title;
}

public double getSalary() {
return salary;
}

public void setSalary(double salary) {
this.salary = salary;
}
}

JavaBeans are also commonly referred to as POJOs (Plain old Java objects). The terms are not entirely synonymous, as a POJO refers to a specific type of class, but is none the less often used interchangeably.

Tip: Most IDEs can automatically generate the getter and setter methods for a class' attributes, so don't waste your precious time doing it! In Eclipse just right click any where on the code screen select source>generate getters and setters, and follow the instructions. Simple as pie!