Archive for the ‘workplace’ Category

The worst codebase I’ve seen in my life

Wednesday, March 30th, 2011

I recently inherited a huge legacy project (let’s call it FailApp) which features brutally substandard code. I’ll present the best gems here, not as a rant, but as a case study of what is possible to be delivered in the software industry for a six figures sum of money.

The gems are categorized in three levels and (due to popular demand) each contains an oneliner of what the author should have done instead.

1) the LOLs

The LOLs are code gems that when you discover them you laugh out loud. They are so funny that you’ll mention them to your coworkers while drinking beer or even post them in a forum in order to have a laugh. They are little harmless anecdotes of failure that the average Joe programmer will do. They are usually the result of incompetent project management (stuffing serious projecs with baby developers) and total absense of industry standard practices such as code reviews, unit tests and code conventions.

2) the WTFs

The WTFs are code gems and design decisions which are totally perverted. You’ll discover some of them after an hour worth of debugging and they are not very funny but rather piss you off. They cause problems in the health of the project and they are the reason why the client ditched the original authors of the app and brought it to you.

3) the showstoppers

Things get hard and serious here. The showstoppers are fatal, dangerous and inexplicable design decisions that the original author made which make your brain explode. They are hard to deal with and will usually cause serious bottlenecks to the application and irreversible data corruptions. When you discover them you will immediatelly call an urgent meeting with the management to explain the situation. These are no fun stuff and probably written by people who have no idea of what they are doing. These problems usually cost serious amounts of money.

The code snippets of the FailApp have not been changed at all. In this case there isn’t any “innocent” to protect since serious harm has been already done with this codebase.

So, here we go.

LOL#1
“Prod” in the application context name. So the staging environment URL looks like http://123.12.34.123:7001/FailAppProd and the production http://123.12.34.134:7001/FailAppProd. Good luck remembering which one is which.

Solution: Not use the environment name in the URL at all. If necessary provide variability on deployment descriptors (possibly upon build generation) which configures “dev”, “prod”, “staging” in the context name.

LOL#2

EscapeIlegalWords eiw = new EscapeIlegalWords();
foo = eiw.escapeIlegalWords(foo);

Yes, we’ve got a spelling mistake here and a really bad local variable name. But the real laugh comes when you navigate into the method:

public static String escapeIlegalWords(String code) { 
    code = code.replaceAll("&lt;", "<");
    code = code.replaceAll("&gt;", ">");
    code = code.replaceAll("&amp;", "&");
    code = code.replaceAll("&apos;", "'");
    code = code.replaceAll("&quot;", "\"");
    code = code.replaceAll("&#13;", "");
    return code;
}

- a new instance for calling the static method? ouch…
- oh I see, there aren’t any “illegal words” here, it simply does something with html which should be done in the template anyway…
- damn, this is the opposite of escaping!
- class name doesn’t make any sense at all

Solution: Fix mentioned issues.

LOL#3

session.setAttribute("contentXML", null);
session.removeAttribute("contentXML");
session.setAttribute("contentOwnerList", null);
session.removeAttribute("contentOwnerList");
session.setAttribute("structuresVector", null);
session.removeAttribute("structuresVector");
session.setAttribute("selectedThematic", null);
session.removeAttribute("selectedThematic");
session.setAttribute("selectedTarget", null);
session.removeAttribute("selectedTarget");
session.setAttribute("targetList", null);
session.removeAttribute("targetList");
session.setAttribute("thematicList", null);
session.removeAttribute("thematicList");
session.setAttribute("metadatas", null);
session.removeAttribute("metadatas");

- yes, please do make sure that you really remove those variables from the session… removing them twice will eventually do the trick.

Solution: Remove the setAttribute(…, null) statements because they are redundant.

LOL#4

ArrayList arrActions = new ArrayList();
HashMap order = new HashMap();
public ArrayList getHighLights(int idStructure, int language, int home) { ...

- thank you very much for declaring on concrete type. ever heard of Interfaces and the Collections API design philosophy?

Solution: Declare on Interfaces which is enough for these cases.

LOL#5

ArrayList avlanguages=null;
if (request.getAttribute("avlanguages")!=null){
    avlanguages=(ArrayList)request.getAttribute("avlanguages");
}
<%if (avlanguages!=null && avlanguages.size()>0){%>
<%for(int x=0;x<avlanguages.size();x++) { %>

- yes, this is too much Java code inside JSP pages instead of using JSTL’s <c:forEach...

Solution: The view layer should use JSTL and not JSP scriptlets.

LOL#6

Some spelling mistakes which will definitely complicate greping for information in logs and code:

END GENERTAION THEMATICS.
updateStatusDocumentDeplubishCron()

Solution: Avoid spelling mistakes.

LOL#7

CommonDatosPopUp pop = new CommonDatosPopUp();
pop = (CommonDatosPopUp)popUp[i];

- that is great. thanks for instantiating something only to throw it away. it does make sense in case the constructor is firing a missile though.

Solution: Declare and fetch from array in one line avoiding the unnecessary construction of an object.

LOL#8

ArrayList List = new ArrayList();
List = (ArrayList) baseManagerDao.getPosition(baseItemIdVar);
for (int i = 0; i < List.size(); i++)

- once again, create that empty ArrayList() and then throw it away
- declaration on concrete Collection type
- iterating a Collection datastructure using index
- exceptional naming of variable List to look like the Interface List (I wonder why the language allows such a raping of itself here)

Solution: Fix mentioned problems.

WTF#1

if (cm.getBlockLevels() != null) {
    request.setAttribute("blocklevel", cm.getBlockLevels());
}
if (cm.getUsers() != null) {
    request.setAttribute("users", cm.getUsers());
}
if (pm.getSigGroupPub() != null) {
    request.setAttribute("siggroups", pm.getSigGroupPub());
}

- hm… cm and pm (really bad local variable names) are managers which delegate calls to DAOs. These DAO methods (probably hitting a database) are being called twice
- and why do we have to nullcheck in the first place? if the result is null we can simply put null (remove) into the request attrs. (and no, these variables where not previously set into the request by another piece of code).

Solution: Remove the if statements altogether. If the statements are necessary assign result from managers to local variables to avoid double DAO method execution.

WTF#2

While trying to fix something I searched for “siggroup”. Notice the variations of the key, all apearing in the same (2000 line) controller:

request.setAttribute("siggroups", pm.getSigGroupPub());
request.setAttribute("sigGroups", sigGroups);
request.setAttribute("SigGroups", hm.getSigGroups(Integer...

- zero consistency is the salt of the programmers life…
- the best part though is in the template:

List sig = (List) request.getAttribute("sigGroups");
if(sig == null) {
    sig = (List) request.getAttribute("SigGroups");
}

- good luck finding which collection you are rendering on screen now…

Solution: Be consistent in the naming of your variables, especially those which are being used in another layer of the application, the view layer. Never do such acrobatics with the capitalization of variables. Once again, use proper names.

WTF#3

There is no javadoc and the most crucial parts of the app are commented in a non English language, including non-ascii characters. http://translate.google.com/ to the rescue.

Solution: Unless your company code style guidelines allow it, never use non-English in projects, especially EU funded ones where you’ll need to deliver full source code later on. Also, non-ascii characters may make some systems of the deployment process choke (e.g peers with old editors, old source diff programs, badly installed C.I environments etc). Also they can become the causes of bugs. e.g can you spot the difference between String action = "NULL"; and String action = "ΝULL";? This can cause problems, that’s why some people decide to never allow non-ascii characters into their IDE so they can catch these issues early on.

WTF#4

Classes with 2000 lines of code methods and 14 level nested ifs. These are usually do-everything controllers which serve many unrelated things from the same codebase (page results, binary downloads, csv). These are usually replicated 10 times with minor differences to accomodate slightly different use cases. Nough said.

Solution: It has happened to all of us. It’s called spaghetti code. When it happens try to think of a better design. If you can’t, please consult the lead developer of the project for assistance. Spaghetti code will bite you back sooner than you expect.

WTF#5

pubHighlights = cm.getHighLights(structId, userLang,
					Constants.PREDEFINED_SEARCH);

- ok, we are using constants for variability instead of different methods or inheritance
body of method:

public ArrayList getHighLights(int idStructure, String lang, int home) {
    ...
    if (home == 1) {
        listado = commonDao.getHightLightHome(idStructure);
    } else {
        listado = commonDao.getHightLightPredefinedSearch(idStructure);
    }

- facepalm for home==1 instead of Constant. good luck with debugging when that constant changes
- by the way it turns out that the initial call should send Constants.HOME instead of Constants.PREDEFINED_SEARCH. It just happens that both equals 1.

Solution: Use OOP practices for solving such problems. If you can’t and need to use constants please use enums. If you can’t use enums and need to use primitive constants please do make full use of them (and not partial, as in this case).

WTF#6

Absence of templating reuse. The 150+ JSP templates contain everything from html declarations to website footer (with copyrights and everything). Only with minor and insignificant differences due to inconsistent copy pasting of headers and whole pages with minor changes. Ever heard of include?

Solution: Do not copy paste like crazy. By copy pasting sections instead of reusing them you may end up with templates which are as complex as your code. All templating systems offer facilities for reuse.

WTF#7

Form validation for the brave:

if (appForm.getFileCV() == null || StringUtils.isEmpty(appForm.getFileCV().getFileName())){
	errors.add("fileCV", new ActionError("error.fileCV.required"));
}else if (!appForm.getFileCV().getFileName().toLowerCase().endsWith(".doc") && !appForm.getFileCV().getFileName().toLowerCase().endsWith(".pdf") 
		&& !appForm.getFileCV().getFileName().toLowerCase().endsWith(".rtf") && !appForm.getFileCV().getFileName().toLowerCase().endsWith(".sdc") 
		&& !appForm.getFileCV().getFileName().toLowerCase().endsWith(".zip") )
	errorExtension = true;
if (appForm.getFileLetter() == null || StringUtils.isEmpty(appForm.getFileLetter().getFileName())){
	errors.add("fileLetter", new ActionError("error.fileLetter.required"));
}else if (!appForm.getFileLetter().getFileName().toLowerCase().endsWith(".doc") && !appForm.getFileLetter().getFileName().toLowerCase().endsWith(".pdf") 
		&& !appForm.getFileLetter().getFileName().toLowerCase().endsWith(".rtf") && !appForm.getFileLetter().getFileName().toLowerCase().endsWith(".zip")
		&& !appForm.getFileLetter().getFileName().toLowerCase().endsWith(".zip"))
	errorExtension = true;
/* if (fileForm == null || StringUtils.isEmpty(fileForm.getFileName())){
	errors.add("fileForm", new ActionError("error.fileForm.required"));
}else*/
if(appForm.getFileForm() != null && !StringUtils.isEmpty(appForm.getFileForm().getFileName()))
	if (!appForm.getFileForm().getFileName().toLowerCase().endsWith(".doc") && !appForm.getFileForm().getFileName().toLowerCase().endsWith(".pdf") 
		&& !appForm.getFileForm().getFileName().toLowerCase().endsWith(".rtf") && !appForm.getFileForm().getFileName().toLowerCase().endsWith(".sdc")
		&& !appForm.getFileForm().getFileName().toLowerCase().endsWith(".zip"))
	errorExtension = true;
if(appForm.getFileOther1() != null && !StringUtils.isEmpty(appForm.getFileOther1().getFileName()))
	if (!appForm.getFileOther1().getFileName().toLowerCase().endsWith(".doc") && !appForm.getFileOther1().getFileName().toLowerCase().endsWith(".pdf") 
			&& !appForm.getFileOther1().getFileName().toLowerCase().endsWith(".rtf")&& !appForm.getFileOther1().getFileName().toLowerCase().endsWith(".sdc")
			&& !appForm.getFileOther1().getFileName().toLowerCase().endsWith(".zip"))
		errorExtension = true;
if(appForm.getFileOther2() != null && !StringUtils.isEmpty(appForm.getFileOther2().getFileName()))
	if (!appForm.getFileOther2().getFileName().toLowerCase().endsWith(".doc") && !appForm.getFileOther2().getFileName().toLowerCase().endsWith(".pdf") 
			&& !appForm.getFileOther2().getFileName().toLowerCase().endsWith(".rtf")&& !appForm.getFileOther2().getFileName().toLowerCase().endsWith(".sdc")
			&& !appForm.getFileOther2().getFileName().toLowerCase().endsWith(".zip"))
		errorExtension = true;
if(appForm.getFileOther3() != null && !StringUtils.isEmpty(appForm.getFileOther3().getFileName()))
	if (!appForm.getFileOther3().getFileName().toLowerCase().endsWith(".doc") && !appForm.getFileOther3().getFileName().toLowerCase().endsWith(".pdf") 
			&& !appForm.getFileOther3().getFileName().toLowerCase().endsWith(".rtf")&& !appForm.getFileOther3().getFileName().toLowerCase().endsWith(".sdc")
			&& !appForm.getFileOther3().getFileName().toLowerCase().endsWith(".zip"))
		errorExtension = true;

Solution: Don’t do this. All MVC frameworks offer some sort of validation facility in order to avoid code soup such as the above. Even if it doesn’t, try to extract the most repeated part of the validation into a method which you’ll reuse.

WTF#8

There are methods which return Vector (yes, 1999 called) and it turns out that the result is never being used but instead the purpose of the method is to mutate the parameters. Smart.

Solution: Instead of Vector use a List. Methods should not have sideeffects and when they do they should mention it in the documentation or reveal it in the method name. Also, returning an unmodified object only to sideeffect the arguments is very confusing. If the method’s logic changes during implementation please try to adapt its signature so it keeps making sense.

showstopper#1

cm.getHighLights is an expensive operation (calculates the nested menu of the website) and the following code is supposed to introduce caching into the game:

ArrayList pubHighlights = (ArrayList)request.getSession().getAttribute("publicationsHighlights");
if(pubHighlights == null || pubHighlights.size() == 0)
pubHighlights = cm.getHighLights(structId, userLang, Constants.PREDEFINED_SEARCH);
request.getSession().setAttribute("publicationsHighlights", pubHighlights);

- it stores the result in the http session so there is a lot of waste of memory in case we have many users
- the generated menu takes into account “structId” and “userLang”. The cache key is only one though (“publicationsHighlights” in the session), so if the user changes structId or userLang, the menu stays the same
- changes on the menu structure are not reflected to already cached clients. They’ll see these changes only if they get a new session (come back later, use another browser etc)

Solution: Think of your cache design. Does it make sense or does it brake the UI and the server? In this case the cache should be in the application layer and the key should take into account all parameters which should modify the appearance and behavior of the cached object.

showstopper#2

Application “does things” to the database on view. Things == if stuff are not there it silently creates them, so for example if you visit the about page of the French site and there is no content there (either from CM error or data corruption) it simply creates an empty one and inserts it into the database. This is nice and useful especially when the application thinks that there isn’t any content there, so after a couple of days you’ll find thousand of empty “about” pages under the French site waiting to be fixed by you.

Solution: This is dangerous. Don’t do it. GET requests should rarely modify the database.

showstopper#3

Total incompetence in exception design and handling. The usual anti-pattern of swallow and return new ArrayList() is followed through the system. Database errors are masked and the system goes on doing what it was doing (e.g continuing with other parts of data changes, email dispatching etc).

Solution: Learn about exception handling and how they make sense in your application’s layers. Have a look at 1, 2 and 3.

showstopper#4

“Change navigation element==edit property” anti-pattern. This is sick. Imagine a CRUD page with a couple of filters on top and an entities listing below. In the year filter you choose 2010 and hit GO. The listing is updated with entries from 2010. Now you change the year filter to 2011 but do not hit GO. Instead you hit EDIT on one of the 2010 entities below. What happens is that the 2011 value from the filter is transfered into the (hidden) element of the edit form. As soon as you hit SUBMIT the entity now belongs on 2011. Nice.

Solution: Don’t do this. The application should have clearly defined use cases for modifying objects. Never trust the UI.

showstopper#5

The search is FUBAR. A single search for “foo” issues 200.000 db queries and requires 5 minutes on the production server because:
- it first does “select *” the whole publications database in sorted batches of 1000 back to a collection.
- it then feeds this collection into a method which filters things out.
- while filtering some entity methods are accessed and due to bad fetch plan from hibernate tons of N+1 statements are executed.

Solution: When developing try to fill in your test database with tons of data to see how your use cases scale. For this particular issue, learning about the ORM’s fetch plans and how these relate to your model and use cases is very useful.

showstopper#6

“Toxic servlets hierarchy”. All actions extend something (a base class) which extends servlet. The base class provides a public static spring factory field which is initialized on boot of the servlet. Yes, the only reason of existence of this base class is to provide this field and the actions extend it in order to get access to this public static field. Great.

Solution: Don’t do this. If you use Spring then use it properly.

showstopper#7

Log4j & hibernate initialization rediscovered! Both libraries are being configured in the following fashion:
- read the log4j.properties and hibernate.cfg.xml configuration files from a custom location using a ContextListener
- write contents into a new file in the server’s root folder
- load from there
- documentation states that if application cannot boot the application’s configuration files should be removed from the server’s root folder!

Solution: Both frameworks require the configuration file in the default classpath. No acrobatics required.
The end.

The * stupidest things I’ve done in my programming job

Saturday, February 7th, 2009

I’m not ashamed of those sins any more, so here you go :)

1. ORM

Stupidity
Building my own Object Relational Mapping framework.
Consequence
Project is a mess after 2 years of maintenance with hardcore hacks to bypass my own ORM and call custom SQL queries.
What should I have done
Use hibernate, iBATIS, Cayenne or something similar.

2. EAV

Stupidity
Using an Entity-Attribute-Value model database schema design.
Consequence
Non scalable solution and total impossibility to run any useful queries on the database level.
What should I have done
Use an ordinary normalized database schema design.

3. Database Access

Stupidity
Synchronize (serialize) database access using one shared connection.
Consequence
Zero scalability. Very slow response times when more than 10 users where using the application.
What should I have done
Don’t do that and use a connection pool such as c3p0 and use a “new” (reused) connection returned from the pool for every request/response cycle.

4. IDE

Stupidity
Avoided learning and using an Integrated development environment.
Consequence
Inability to build test and deploy the application quickly and generally do anything useful.
What should I have done
Get familiar with an IDE. NetBeans, eclipse etc.

5. Transactions

Stupidity
Not using them.
Consequence
Corrupt data in an application involving e-shop like functionality.
What should I have done
Use database transactions. When in MySQL use InnoDB.

6. Prepared Statements

Stupidity
Using Statements, string concatenation and naive character escaping to assemble my own “safe” queries.
Consequence
SQL Injections possible in my application. I managed to login using ‘or 1=1;delete from users;– and alter the database state in a very nasty way.
What should I have done
Use Prepared Statements which correctly assemble and escape the query properly depending on the JDBC driver used.

7. Business Logic

Stupidity
Doing it in the template (JSP).
Consequence
Messy non maintainable application.
What should I have done
Do it in an MVC style with servlets or with a Front Controller. Even better by using an existing open source MVC framework such as Struts, Spring MVC etc.

Of course, all the bad choices above have probably made me a better programmer.

5 sins of subversion usage

Saturday, May 5th, 2007

Whether you develop alone, or with others, there are some things that you should avoid doing when using subversion (or any other version control system).

1. Break the build and/or tests

The problem

It’s very common to break the build because you removed a class or changed a method contract. This can sometimes get frustrating. Others, who continue working on the project, will either have to tell you that you broke the build (thus asking you to fix it), or fix it themselves. This is something that requires communication and time. If more than one person fixes the problems, the possibility of conflicts is high.

Solution

a) Do a clean build and run all tests before committing. That is Shift+F11 and ALT+F6 in NetBeans.
b) Use a Continuous Integration system which does this for you.

2. No comments or bad comments

The problem

Examples of bad comments (yes, the first one is an empty string):

  •  
  • uploaded Member.java
  • Deleted some files
  • Improvements

These comments are useless. Everybody can see from the log that Member.java was “uploaded”, or that some files where deleted. It is also not useful to say “improvements”, because it is very general, and also because it’s common sense that you are working on a project only to improve it (and not to make it worse).

Solution

Always write comments about changes in the software, and not about which files have been changed. Try to comment in terms of software modules, requests and bug fixes. You could even use issue numbers from your bug tracking software. Examples of good comments would include:

  • Changed authentication to use cookies instead of the http session
  • Changed from dbcp to c3p0
  • First stages of html/css layout integration
  • mock dao tests
  • fixed mail scheduler (Issue 5532)
  • Reporting engine now supports PDF export

One of the advantages of having comments such as the above is that you can easily select a range of dates and produce a change log.

3. Committing useless files

The problem

Some people commit stuff such as:

Sometimes Thumbs.db and _notes end up deployed on the production server. This is useless, bad and inappropriate.

Solution

Never commit stuff that should not be committed. Learn how to use the ignore/exclude patterns of your favourite svn client. In TortoiseSVN a the exclude/ignore pattern “thumbs.db _notes dist build nbproject” will do the job.

4. Not committing for days (or weeks)

The problem

A developer does not commit for days (or weeks) because he is lazy, always leaves from work in a rush, or hasn’t got a compiling application (for days… or weeks). Some reasons why this is very bad are:

  1. Code reviewer can’t review the code.
  2. Developer might be working on something that has already been done before, but nobody can tell him so.
  3. Developer might be trying to solve problem in a wrong way, but nobody can see that.
  4. Anxiety levels of Project Lead increases because he doesn’t know about work being done.
  5. Merging becomes really hard due to many (and difficult to resolve) conflicts.
  6. The possibility of completely loosing work increases as hard drives tend to fail when you least expect it.

Solution

Commit at least once a day. If you are working on a feature or fix that is completely unrelated with work that others do, consider branching.

5. Not following naming/structure conventions

The problem

When a repository is shared between many different people with many different projects, things can get messy:

svn://192.168.1.44/2006-playboy_website
svn://192.168.1.44/COCA_COLA
svn://192.168.1.44/JAVA-DEVELOPMENT/coca-cola-project
svn://192.168.1.44/JAVA-DEVELOPMENT/coca-cola-project-DELETE_THIS
svn://192.168.1.44/JAVA-DEVELOPMENT/coca-cola-project-static-layout
svn://192.168.1.44/Project_1
svn://192.168.1.44/backup/Project_1
svn://192.168.1.44/backup/coca-cola-project-DELETE_THIS
svn://192.168.1.44/dynamic site coca cola
svn://192.168.1.44/important_docs
svn://192.168.1.44/java-projects
svn://192.168.1.44/java-projects/bar
svn://192.168.1.44/java-projects/foo
svn://192.168.1.44/java-projects/foo_1
svn://192.168.1.44/java-projects/foo_old
svn://192.168.1.44/playboy_PROPOSAL_2002
svn://192.168.1.44/project1
svn://192.168.1.44/project1_
svn://192.168.1.44/οι εικόνες

Solution

Use naming and structure conventions. Make up your own, propose them in your team and adopt them. A possible convention could be:

  1. Only lower case in folders
  2. No native characters in folders
  3. Only dashes in folders (no spaces or underscores)
  4. Folder structure always uses root/account name/project name/project artifact

These simple rules greatly improve company’s xyz repository structure:

svn://192.168.1.44/coca-cola/dynamic-site/documents
svn://192.168.1.44/coca-cola/dynamic-site/project
svn://192.168.1.44/coca-cola/old-stuff
svn://192.168.1.44/coca-cola/static-site/old-site
svn://192.168.1.44/coca-cola/static-site/site1
svn://192.168.1.44/playboy/dynamic-site/community
svn://192.168.1.44/playboy/dynamic-site/forum
svn://192.168.1.44/playboy/dynamic-site/project
svn://192.168.1.44/playboy/proposals
svn://192.168.1.44/playboy/static-site/old-site
svn://192.168.1.44/playboy/static-site/site1
svn://192.168.1.44/xyz/cms/project
svn://192.168.1.44/xyz/cms/static-layout
svn://192.168.1.44/xyz/interns/documents
svn://192.168.1.44/xyz/interns/nick
svn://192.168.1.44/xyz/interns/project-1
svn://192.168.1.44/xyz/interns/test-project
svn://192.168.1.44/xyz/website/layout-1
svn://192.168.1.44/xyz/website/layout-2
svn://192.168.1.44/xyz/website/layout-3

Good luck.

Interesting reads:
- KDE SVN Commit Policy
- Version Control with Subversion

Learn to use Google

Tuesday, April 3rd, 2007

What is Google

Google is the best search engine around. It is very user friendly, easy to use and has tons of features. By using Google you can have all the knowledge in the world, available to you; in a snap.

The Problem

Although the facts above sound very nice, and everybody seems to be using Google, it is still (on 2007) considered natural for non technical people (my mom, your mom etc) to be hands tied and feel “blind” when using the Internet. It is not expected from them to be able to find the information they want, easily and accurately, although this is not hard at all.

When talking for technical people though (developers, designers, analysts, managers etc) it is completely unacceptable when one (or more) of the following behaviors are observed:

  1. Complete ignorance of the search engine (rare).
  2. Boredom to such degree where searching is not an option (common).
  3. Inability to find correct search keywords for the topic in question (common).
  4. Incompetence to use Firefox properly (Tabs, Search Bar, maximal use of keyboard) in a degree that makes searching slower than it should be, thus turning away the individual from searching as often as possible (common).
  5. “Can’t be bothered-I’ll ask my co-worker” syndrome (very common).
  6. “I give up, this is not possible – has not been done before” syndrome (rare).

The Facts

These behaviors are definite showstoppers. They make you a less productive and irritated person. No need to analyze that further.

The Solutions

  • Do you observe such behaviors on your employees? Time for a chat with them. Have someone show them how “the Google” works.
  • Do you observe such behaviors on you; on your daily work routine? You can do better – and please start today!

And why do you care?

I’ve been watching people, engaging into long discussions with other people about that tool… that css compressor tool that has been mentioned once in a meeting… which meeting? Yes, that meeting, oh yes… and what does it do? It strips whitespace and makes the css file less readable and blah blah blah…
- google: css compressor
1st result

I’ve been watching people, trying to explain what they want to achieve, and whether it is possible. They want an ajax thingy which will update part of the screen without refreshing the whole screen (irony?), which will be displaying chat messages from many people, possibly by polling the server every so ofter… blah blah blah
- google: ajax chat example poll server
1st result

I’ve seen people lifting themselves (literally) from their seat, walking down the aisle, to ask a colleague to give them (yes give them) the URL where from they can download NetBeans!
- google: download netbeans
1st result

Conclusion

Man… it’s not that hard. Make your lives easier, and let the people around you work! If you don’t know how to use Google, then google for a google tutorial :)

Happy googling…

Unit testing needs time?

Tuesday, March 20th, 2007

New developers will sometimes complain about how Unit Testing requires a lot of time. How much it slows them down, and how they cannot see any good in writing tests for their code.
There are many scenarios which prove that unit testing is necessary. These include speed of development, ability to refactor easily, test-driven development, testing without the need of web container, testing with mock objects etc.

My favorite though is the “client calls to report something weird” scenario. I’ve seen it many times and it goes something like this:

Scenario:

  1. Your webapp is deployed, weeks ago, and you’ve moved on with a new, exciting project. Everything is feels good, as you’ve completely forgotten about sins of the past (not writing tests)
  2. Client calls you to report “something weird”.
  3. You stop whatever you are doing at that moment to switch to that project.
  4. You connect (VPN or whatever) to the remote server to see possibly logged exceptions.
  5. You collect your data.
  6. You try to reproduce the error locally, on the development server.
  7. You find the bug.
  8. You issue the bug in the bug tracking system.
  9. You fix the bug.
  10. You build for deployment.
  11. You deploy (while solving any possible application version issues).
  12. You contact the client.
  13. Wait for his confirmation that the bug has been corrected.
  14. You deliver the bug in the issue tracking system.
  15. Finally you commit the code back to SVN.

…or in whatever order feels more natural to you.

If the above scenario feels OK, and you need some hints on why you should try to minimize such cases, have a look at the costs involved:

Costs:

  • All of these actions need time. Your time.
  • Most of them require a context switch. Not only you lose X minutes from your previous work, but also need Y minutes to get back into the flow (mind state) you had previously.
  • Some of these steps might not be what you really want to be doing (talking directly to the client).
  • You become a slow worker producing bad code.
  • People will never trust you with that mission critical application, because your code has a tendency to develop “random features” on runtime (usually involving exciting names such as NullPointerException).

Facts:

This scenario can definitely happen for tested code. Bugs will always creep into your code no matter what. The point is try to at least minimize the stupid ones. Cases which can easily be covered by unit tests.
Unit testing is important (if not mandatory). If you feel that it needs time, you have to press yourself and do it. It’s a matter of weeks until you become test infected and experience how your software becomes better in less time.

Hints for NetBeans users:

  • Got a class that you want to create a JUnit test for? CTRL+SHIFT+U
  • Got a class and want to jump to the unit test (and vice versa)? ALT+SHIFT+E
  • Want to test the project? ALT+F6

Happy testing.

Java Code Conventions

Saturday, February 24th, 2007

When writing Java code you must follow the Code Conventions for the Java Programming Language. It’s a document written by Sun back in 1997. Why should you read such an ancient (in computer science terms) document?

Code conventions are important to programmers for a number of reasons:

* 80% of the lifetime cost of a piece of software goes to maintenance.
* Hardly any software is maintained for its whole life by the original author.
* Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.

Some people tell me that they cannot change their style, because that’s how they are used to coding. Fair enough. Do whatever you want when coding alone, in your home. But not in a professional environment. If you can’t be bothered, do us a favour and leave. Resign. Start selling popcorn. Whatever.

I have a serious problem working with people who commit Java code which looks like this:

public class persons {
public void PersonSave(persons p) {
package foo.bar.personUtils;
public static final String foo = "whatever";
whatever()
{
  // do stuff
}

Seriously, please try to read the following piece of code found in a real life project. Does this look like Java?

if(e<0.0)d= -d;
if(d!=0.0)for(int i=0;i<dim;i++)this.n[i] = this.n[i]/d;
else this.tW.writeString("normalise: non simplex");
Object leftList = null, rightList = null;
try{ leftList = c.newInstance();}
catch(Exception e){tW.writeString("sort:error1 ");return null;};

OK, this style might have been good in an Obfuscated Code Contest, but it definitely does not get you going in the workplace.

Good luck