Agilia 2014, Budapest

I received great news. They accepted my proposal I had submitted to Agilia 2014, Budapest. I am going to talk about Conversation Patterns for Software Professionals.

We have created lots of tools which are intended to structure fuzzy or unclear business needs. We have created use cases, user stories, acceptance test and so forth.

Although the tools above were designed to improve collaboration with customers, we use them to hide ourselves from business people. Instead of talking to an individual, we tend to complete the forms.

The issue motivated me to start working on Conversation Patterns for Software Professionals, which are techniques for having better conversations with stakeholders and drilling their real needs. The Patterns makes soft skills more technical guy-friendly and easier to apply.

I do believe that quality of answers you get attests to quality of questions you have asked. So, which of the following questions will give the most valuable informations?

• Do you want to add new items to the backlog?
• What of new items you want to add to the backlog?
• What of new features you're going to use next week?

Not sure? Join this presentation and verify questions you use to ask.

This will be my first conference outside of the Poland as a speaker, so wish me luck!:)

Agile Organisational Culture

One of the most painful lacks of applying Agile is, in my opinion, the situation when we incorporated an agile structure but organisational or working culture remains pre-agile.

Organisational culture includes the: human behaviours, skills, beliefs, organisational values, mission and visions, language expressions, symbols, norms what is allowed or what is not inside the organisation. So all these things putting together make a mental shift toward being agile.

Applying Scrum or any framework in most cases gives a structure only. I mean: PO, SM, Team, Backlog, charts, meetings, workflow and so forth. But it's not enough to Scrum brings benefit to your organisation.

Even if DevTeams and business teams commit they know they are a-g-i-l-e now, they will fail because of misunderstandings what agile organisational culture components (listed above) mean to them.

As far we give the agile structure to people, we also need to align every part of organisation with ubiquitous agile culture.

Nice Move With ValueSetter

I've been working on software architecture refactoring for last couple weeks. During a workshop one of architects showed me an interesting approach.

We were applying MVP-like style and then faced with the question: How a Presenter should tell a View to change its state?

Brute force approach looks like following:

public class Presenter {

 private View view;

 public void doSomething() {

//Here, services are processing something really important

 view.setTitle( "Updated" );
 view.setName( "New name" );
 }
}

public class Form extends JFrame implements View {

 private JTextfield nameTf;

 @Override
 public void setTitle( String title ) {
  setTitle( title );
 }

 @Override
 public void setName( String name ) {
  nameTf.setText( name );
 }
}

Well, this is actually ok, but the more components you have on the form, more verbose View interface becomes.

The move I am talking above is encapsulating a setter into separate object. Look here:

public abstract class ValueSetter {

private static Map<Class<?>, ValueSetter> SETTERS;
 
 static {
  SETTERS = new HashMap<Class<?>, ValueSetter>();
  SETTERS.put(JTextField.class, new JTextFieldSetter());
 }
 
 public static ValueSetter get( Class<?> type ) {
  if( SETTERS.containsKey(type) ) {
   return SETTERS.get(type);
  }
  
  throw new IllegalArgumentException( "Missing ValueSetter for " + type );
 }
 
 public abstract void set( Object target, Object value );

 private static class JTextFieldSetter extends ValueSetter {

  @Override
  public void set(Object target, Object value) {
   ((JTextField)target).setText( (String) value );
  }
 }

 private static class JFrameSetter extends ValueSetter {

  @Override
  public void set(Object target, Object value) {
   ((JFrame)target).setTitle( (String) value );
  }
 }
}

Now it is possible to write more elegant code:

public class Form extends JForm implements View {

 private Map<String, JComponent> components;

 @Override
 public void updateComponent(String id, Object value) {
  JComponent component = components.get(id);
  ValueSetter.get(component.getClass()).set(component, value);  
 }
}

So thanks Marcin for this nice tip and fresh idea for me ;)

Extremely Pragmatic Software Architecture

Since the Measuring Software Architecture I have beeing digging through two systems written in not so mainstream technologies and some crazy idea occurred to me.

Do you know what is the biggest problem for a developer when one starts to develop a system? Lots of Mess (upper case on purpose). All that hundreds of hundreds interfaces with one, two or three methods. All that Abstract*, *Impl, Generic*, *Helper, *Support classes, which implement all mentioned interfaces make a developer really confused.

Are the patterns or DDD or something else the remedy for that? I am not sure.

First. You may think that applying quasi-remedies above reduces cost of introducing a newbie to the project. I disagree. A developer learns the technical meaning of the source code very quickly. Really big cost is acquiring in business domain.

However domain-agnostic developer writes poor code, but perfectly understanding how the domain works is not critical for one to understand what is technically going on in the code.

To be honest, I have met few software professionals who perfectly understand how the domain worked. Most of us knows just only enough (or little bit less) to make the feature working (at the moment).

Second. You may think that applying quasi-remedies increases code-readability what improves communication, what improves quality, what improves velocity, what improves business value. Well, this is true, but..

I observed when a project breaks all code-readability techniques and crazy naming conventions and macro-design techniques are used CONSEQUENTLY by a team, then some phenomenon happens. People align their perception to consequently used (even crazy) conventions and techniques. And then they are becoming productive developers. It takes time, but this is the fact.

So, my idea is the crucial thing for working effectively with software architecture is...keeping order inside the project, packages, folders, classes, methods and so forth. Order means: not so much code in one place, not so much dependencies between items and avoid cyclic dependencies if possible.

Do you know what I mean? No methodologies, no *Driven* approaches, no patterns maybe, just ordinary old-fashioned order.

When you focus yourself on listed approaches first, you may forget what they were invented for. Being focused on keeping order doesn't make you most modern developer, but you will know what will be going on in the project, what to do and how to keep the code simple and clear at the moment. And I think this knowledge is enough. At the moment, of course.