Feedback driven development

All modern software development methodologies are focused on increasing the feedback and taking advantage of it. One of the fundamental assumptions is that trying something out (getting feedback) is more valuable than the cost of doing it wrong. This works fairly well if we are getting quick and reliable feedback. However, does this equation still apply if we are not getting timely/quality feedback?

Advertisement

I wrote this post some time ago. Decided to update it primarily due to inspiration got from Growing Object-Oriented Software, Guided by Tests book

Ürgo Ringo's blob

Following is list of best practices I try to follow when writing tests.

View original post 492 more words

If Java was written as JavaScript

It is interesting how the standards that are obvious in one context/language can be so easily disposed of when working in some other context/language.

Middle of sprint demo

In addition to having demo at the end of sprint some of our teams have demos also in the middle of the sprint.

Automating database migrations

When it comes to automating database migrations then there seem to be two main approaches. First, doing it outside of application by adding database migration into deployment script. Second, is making database upgrade part of application startup logic.

Team Knowledge

I think that team’s successfulness is directly correlated to the ability of using team’s knowledge. This means taking the most out of already existing knowledge and skills of each team member as well as making it possible to accumulate new knowledge and skills.

Implementing uniqueness validation in JPA

One of the typical things one often needs is uniqueness validation across Entities. For example making sure that each user account has unique username. Implementing this check is somewhat complicated in JPA/Hibernate because they will send pending changes in current Unit of Work (EntityManager, Session) to database before executing any queries against same Entity.

Consuming change

Biggest challenges in developing software for external customer are not related to producing software but consuming software.

Set up test state using API when running tests via UI

When writing tests via UI it usually makes sense not to use UI for setting up application state. First, using UI for setup makes your UI tests even slower. Second, you may need to write some additional UI automation code simply for setup.

One team – one language

In many multicultural teams it happens that people start talking to each other using their native language. Main problem is that this way we effectively cut off those in the team who do not understand given language. This essentially means that osmotic communication doesn’t work. If topic is discussed in a language that everybody understands then everyone has a chance to join conversation even if he/she was not addressed when discussion was started. However, if non-common language is used then there is high risk that full potential of the team is not used when decisions are made.