If Architecture Review matters

Hey, how often are your Architecture Review sessions setup?

If teams are senior, there is a lure to run those review sessions not so often. And things are going well, since  senior developers are using proper patterns and communicate together nicely.

The risk triggers when new teams appear and level of seniority is not proven yet. If system design reviews sessions are conducted once or couple of times only, there unpleasant surprises might pop up. Usually issues are experienced once components of those poorly designed systems are integrated. Velocity of new features development is struggling also.

 Leverage the power of conversation, let people discuss the common approach in a structured manner. Do not let it go in uncontrolled manner.

Are Requirements Required

It's difficult to agree with one argument I hear quite often from peers. The wording usually varies like

- What are the requirements?

- We did not receive requirements of proper details.

- Cannot proceed further without requirements.

As per experience, such questions are signals of low team engagement into the product or process. In real life, definitions in Project Charter are quite good baseline to go ahead with development without dependency on additional requirements. 

Statements in Project Charter is enough to get vision on product features of greater impact

- Infrastructure (either terminals, or server side)

- Industry (automotive, financial, publishing, insurance, medical, ...)

- Functionality (either reporting, or data input, or extract and its modifications, ...)

System properly designed should easily accommodate usual request of changing screen flow, adding attributes and modifying entity relationships. This is the only real requirement.

Due date

Quite often can see curios effect of how due date is differently understood by various people.

 I.e. today is Jan 15 and Feb 01 is due date to deliver a function to customer's environment. Rare person can think of some prep and top-bottom decomposition with planning. Most probably activities will be kicked off a bit earlier of deadline day. This is clearly visible Juniors' way.

Mature professional would think ahead, plan backwards and proceed with stuff not that late.

Mitigation is to communicate juniors closer due dates with intermediate goals.

What's good for a process

There is forever ongoing discussion where the golden middle between agility and sophisticated process for quality delivery is. Have clear examples for this.

A good process is like a train bringing you to a destination. Imagine, you're new to the virtual team, go to a tracker and can see all the ongoing things filtered by status or assignee. This is a way for better.

On the contrary, a bad process is pack of obstacles. Imagine, you're sitting at a desk and waiting for formal input (i.e. spec) from your colleague for obvious thing (i.e. database reconciliation). This is a stagnating way.

Demanding

Being demanding towards yourself and peers around is a well known success criteria.

A demand brings a quality through a competition. And that competition is hardly possible in corporate IT due to absence of powerful consumer.

Consumer needed. Where is a consumer?

Other story is with consumer IT, its low cost to enter the market and millions of users.

As a result, all sorts of organisations are borrowing ideas from consumer technology. Smartphones are leveraged for corporate communications. Advanced user experience approach and an in-depth search capabilities are applied to intranet application.

That all came from outside, from non corporate world, from consumer IT.

... read more in Economist article.

Who is senior

Have a clear definition on profile of Senior dev.

Senior dev does take over an uncertainty without clear requirements, quickly transforms it into a working prototype, ready to enhance it in an iterative mode.

The person who knows the solution but speaks on the barriers is not a senior at all.