Adaptive Software Solutions

Test Driven Development The importance of writing tests They force the developer to think of the class design They provide a safety harness while refactoring They ensure that the state of code is always stable New developers can make changes comfortable with the knowledge that if they break something that was working, the tests will inform them Test after development is not the same as test first development. Test after development does not reap all the benefits of test first development Writing the tests Think about the class it’s responsibilities and it’s API Write the tests to test every method and various conditions in the methods Whenever you think of writing a print statement or generate a log, it might be a scenario to include a test Write enough production code to ensure that the tests compile and fail Write production code to pass all tests one by one, while also ensuring that previous tests do not fail What not to test Database entities need not be tested Do not go...

A few days back, I was discussing Agile Timeboxing and estimation with some developers. What follows are some suggestions I gave them and thoughts that emerged from the suggestions. In the examples I have used to explain certain points, I have assumed a J2EE application which has a database, an entity layer, an application layer, Struts Action classes, and JSP's. The concepts can be extrapolated into any other type of application as well. Given a requirement we should be able to determine the amount of time it will take us to fulfill it. This is much easier said than done. Some reasons why we are not able to come up with accurate estimates are: Lack of familiarity with the code base Overestimating our capabilities Underestimating the amount of work needed to be done and it's potential ripple effects Working with gut feel without a proper process to identify the work that needs to be done In this post I will focus on a process that can be used to identify the...

A few days back I came across a very good and informative website. Before you say to yourself... oh no not another website, and skip this post, let me tell you that this one is really good. Like all good things it is community driven. The community bring up the latest new items related to software development on the website, but the most useful content according to me is their interview series. They have interviewed several software luminaries like Joshua Bloch (on API design), Martin Fowler (on DSL's), Ron Jeffries (on Agile), Brian Goetz (on concurrency in Java), and many more. These interviews  are available for viewing on their website. The overall content quality is superlative. I'm sure I have at least got you interested enough to check it out .

There is an interesting discussion going on the Java Posse Google Group on the maximum memory that can be allocated to a JVM. Now if you are running a 32-bit system, then 4 GB is the maximum addressable memory. Of this, the OS (Windows)  takes about 2 GB (though it can be tweaked to take less according to a post on the Java forum), leaving 2 GB for your apps. You could theoretically assign this 2 GB to your JVM, but thread stacks are allocated memory outside of the JVM. So if your application uses a lot of threads, you will have to leave some space for the thread stacks. Now if you use a 64-bit system, then you can allocate a LOT more memory to your JVM, but to do this your entire stack (CPU, OS, JVM, any other dependencies) needs to be 64-bit compliant.  If you want an unlimited heap size for your JVM, you might want to check out Azul . John Reynolds wrote an interesting blog on scaling JVM's with Azul.  By the way of you enjoy listening to podcasts and are into Java, ...