Assumptions I held about software development, that no longer hold true for me

That architecture is more valuable than test

1. Often what we do with software doesn't change that much. Good tests describe what we want to solve with software.
2. Software changes greatly in many directions over time. The architecture we choose today will not "stretch" in every direction of change, requiring significant changes at some point.
3. We can only sell features. Tests are a great description of features. We cannot sell an architecture.
4. The right tests, written at the right level in the application will out live the architecture.

We need to re-write insert any software product from scratch

1. It nearly always takes significant time to re-solve all the simple problems the old system does for your users.
2. The expectation of the user is immense.
3. Software is not construction, the foundations of our system are not in concrete. It's our own perceptions of the complexity of the current solution coupled with our desire to embrace new tools, that limits the changing the current solution. We think it's easier to start from scratch.
4. One of the Facade, Adaptor or Proxy design patterns should be employed to bring fundamental change to a software system.

That you can be faster if you do Agile in software development, but keep all your traditional stakeholder, requirement, release and business management processes.

1. Agility means you are agile from the customers’ point of view, i.e. they are getting something delivered from you every 1-4 weeks.
2. It's hard to release every X weeks, if you can't put work through your production pipeline in less than X weeks.
3. The overhead of breaking work down to fit into short sprints, actually makes the overall work take longer to do in the medium to long run.
4. Agile allows you to maximise the amount of work not done. Can you choose what features not to do?

That I must enter "the zone" to be productive or that I work better on my own.

1. We do require focus in a very busy world. But the zone has no feedback, so we often end up doing the wrong thing.
2. It’s important to come out of the zone frequently so we don’t lose sight of our destination.
3. We do need some quiet time to absorb information and reflect, but this isn’t productive time.

If I am efficient and productive, I am effective.

1. Productive means you are active at building something.
2. Efficient means that you are really great at building something.
3. Effectiveness is measured by the receiver of the output of our work.
4. We often build the wrong thing or we build a lot more than the user needs.
5. It is better to build something small that is used and useful, than to build something large that is never used.

In software development, the "busy" team is the "best" team.

1. It's nearly impossible to visualise the output of software teams.
2. It's even harder to get objective measurement on that output.

Bad developers cause the most bugs.

1. Bad developers usually deliver very little and the issues they create rarely get passed our first test loops, eg Code review and basic integration test.
2. Developers who produce the most code, produce the most bugs.
3. The code that is not written, contains no bugs.

Unit tests test methods

1. Most unit testing is written towards all the methods in every class in our component. It is very tightly coupled to our design.
2. If I have to change the test when I change the source, I can't be sure the method/class/component worked like it did before.
3. The "acid test" for a good unit test is that you can change the implementation without changing the test.
4. Refactoring means that I re-structure & re-write code, but it does exactly the same job it before.
5. Good unit test is written towards the public API.

There are lots of good unit test and TDD articles/books and resources.

1. Most say that for every method you write, you must have at least one unit test. This is wrong.
2. Most say you must design for test. This is wrong. Good tests simulate real use.
3. Most state that the "unit" is the method under test. The unit is the test itself.

---

Thanks to Contributors: Shane McCarron, Rachel O'Toole

Java interview questions - level advanced

This is the third in a series of articles on Java interview questions. These questions require subtle, but important, details of certain parts of Java to be correctly answered. These questions are less obvious than the intermediate questions.

1. Why do we favour the use of StringBuilder over String concatenation?
   String concatenation used to be expensive because it creates more String objects. StringBuilder does not create as many objects and is unsynchronized. In later versions of Java, the compiler optimizes concatenation operator to use StringBuilder automatically on compilation, so it doesn’t matter if you use the “+” operator or StringBuilder.
2. Why is it important to implement hashCode() if we override equals()?
   It is important to override hashCode because the java collections framework relies on hashcodes. Ultimately if two objects are equal they must return the same hashCode, however it is not required that two objects that are unequal produce distinct results, but collections might be more efficient if they do.
3. What is the contract for equals() method?
   It is reflexive: for any non-null reference value x, x.equals(x) should return true. It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true. It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true. It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified. For any non-null reference value x, x.equals(null) should return false.
4. If I have two object of the same type. If I pass the first object to the second object, can the second object directly access the first objects private member fields?
   Yes you can – you do not need to use getter methods or any other “fancy” solution. Private is class private, not object private.
5. Outline how you would use a Future interface in Java?
   A future is used to get the result of an synchronous result from a ExecutorService. The ExecutorService will gather the return values of call() and call back the main application via the future interface
6. What is strictfp? Where would you use it/side effects?
   strictfp makes the JVM put restrictions on the floating point datatypes to ensure they are portable. Some processors are able to make more accurate floating point calculations and the JVM spec allows these to be taken advantage of off. If you use it your calculations will be less accurate, but will be equally wrong on all platforms.
7. How many times does finalise get called?
   Finalise gets called exactly once. If I manage to re-reference the object in my finalise method, making it no long eligible for garbage collection - the next time it comes around to garbage collecting the object finalise will not be called.
8. Explain the substring memory leak problem in Java 1.6:
   http://www.dzone.com/links/r/the_introduction_of_memory_leak_in_java.html
9. Whats the difference between Comparable and Comparator?
   Comparable has one method and makes a class comparable to another. The comparator takes two objects of the same type and applies logic to compare one to another.