The Agile Business Analyst: A Product Owner’s Best Friend

The Agile Business Analyst: A Product Owner’s Best Friend

---

Don't Quit Your Day Job

- Written by Elizabeth Taberner-Mair

There’s so much jargon and lingo in technology that for the everyday businessperson any technology conversation is a difficult and overwhelming experience. But everyday business people have technology needs too. You know everything about your business, but could you translate that into software?

A proficient Agile software development project team depends on a strong and engaged Product Owner to drive the priorities and the product backlog. An effective Product Owner is dedicated and available – do you have the time to be Product Owner for your project? To keep track of the product backlog, answer developer questions, and still fulfill your day job? An Agile Business Analyst can help bridge that gap.

Responsibilities. Let’s start by taking a look at the responsibilities of the Product Owner:

• Backlog definition: meet with stakeholders to define the product, define product epics (features), define the product backlog, define acceptance criteria for each backlog item, prioritize the backlog;
• Backlog grooming: identify dependencies between product backlog items, refine and size the product backlog;
• Define requirements: wrangle details of each story from stakeholders and subject matter experts, support the development of software requirements to meet the acceptance criteria;
• Support the development process: present the backlog at sprint planning meetings, support developers and testers questions throughout the sprint;
• Get the product into the real world: accept and sign-off on an implemented story, manage stakeholder expectations…

Introducing the Agile Business Analyst. For those with little experience in software development, this list is long and frightening. The best types of Product Owners are those who understand the true business need of a project and can provide immediate insight to the value and priority of backlog items.
The role of an experienced Agile Business Analyst can support a Product Owner through the
software development process, providing the development team with a dedicated resource which improves velocity and eliminates blocking issues quickly, and leaves the Product Owner to be business focused. Think of them as a Product Owner Peer – or a Product Owner’s best friend.

Agile BA Skills. An Agile Business Analyst is skilled in software development and requirements
elicitation. They know how to ask the right questions of business stakeholders and SMEs and facilitate prioritization with often dissenting opinions. Agile Business Analysts can design software solutions to meet business requirements and that solve business issues, while simultaneously managing the scope of the solution to ensure that the most business value is delivered for the time spent. They can then translate these designs to developers through requirements including visual models.
To the Agile purist, the role of an Agile Business Analyst is an added layer of communication, which goes against the principles of agility. However, someone is always eliciting detailed requirements and communicating them across the team, be it the Product Owner, a developer, a tester… By enabling a skilled resource to complete these activities, developers and testers are freed up to implement the stories.

Technical Chops. The best Agile BA’s are somewhat technical. They understand the software
development process in detail and can contribute to the development of software architecture and design. They are effective at troubleshooting and understand data and how to access it. This technical merit works both ways – Agile BA’s can communicate business needs to the developers in a technical manner, and can communicate technical challenges and solutions to stakeholders in a not-so- technical manner. This relieves a lot of stress for a non-technical Product Owner (that’s what friends are for!). All Agile BAs at Axispoint have a background in software development and technology.

Enables Cost Reduction. The presence of an Agile Business Analyst at Axispoint enables the hybrid onshore/offshore development model (link?). Developers and other team members can be in remote locations, but software requirements are still elicited with direct customer interaction as Axispoint’s Agile BAs work out of Axispoint’s head office. This face time is essential in getting to the core business problems and for brainstorming solutions with stakeholders; the proximity to the customer enables better communication, but costs remain minimized by not requiring this same proximity for the whole development team.

Scrum Ceremonies. Scrum puts an onus on the Product Owner to be present at all ceremonies to facilitate decision-making and provide requirements direction and input. For a time-crunched Product Owner, the Scrum schedule can be a challenge; the Agile BA can be a proxy when necessary. This includes facilitating Sprint Planning (1.5-2 hours, every 2-3 weeks), participating in the Sprint Retrospective (15-30 minutes, every 2-3 weeks), and participating in the Daily Stand-Up (15 minutes, every day). But as the ultimate “Product Owner”, we always recommend that the Product Owner attend the Sprint Demo (1-1.5 hours, every 2-3 weeks) and Backlog Grooming (1-1.5 hours, every 2-3 weeks)!

Like any good best friend, the more investment you make, the better the outcome – so while the Agile BA can be a proxy, the Product Owner should be highly engaged for the best result.

Dividing Responsibilities. Let’s take another look at the responsibilities of the Product Owner, but now divide them between the Product Owner and the Product Owner Peer/Agile Business Analyst*.

Product Owner	Product Owner Peer / Agile Business Analyst	Together, guided by the POP
- meet with stakeholders to define the product - manage stakeholder expectations	- wrangle details of each story from stakeholders and subject matter experts - identify dependencies between product backlog items - refine and size the product backlog - present the backlog at sprint planning meetings - support the development of software requirements to meet the acceptance criteria - support developers and testers questions throughout the sprint	- define product epics(features) - define the product backlog - define acceptance criteria for each backlog item - prioritize the backlog (final authority coming from Product Owner) - accept and sign-off on an implemented story

Introducing an Agile Business Analyst to a software development project can make it possible for a customer to achieve the Product Owner responsibilities. By leaving the Product Owner to be business focused and working in a partnership, better quality software can be produced with better velocity, and the technical expertise of the Agile BA makes approaching the development team less intimidating.
Would you like to hear more? Contact us to find out how our Analysts can help your organization through a technology implementation.

Back to the Future of ACID: Part 2

Back to the Future of ACID: Part 2

---

Borrowing from ACID patterns to tame eventual consistency (continued...)

- Written by Matt Howard

In Part 1 we explored the notion of data consistency from the perspective of an Oracle database - specifically how Oracle relies heavily on structured logs to give us the consistency guarantees that we have come to rely on. We can often apply this same pattern in our applications to mitigate some of the risks in working with an eventually consistent database. This requires a shift in how we think about our data. Developers think of “data” in terms of the public model that relational databases expose to us - a “column” and a “row”, but we just saw how Oracle operates with much more granularity. “Data” is a specific value at a specific point in time, and this definition of data is what allows Oracle to manage consistency. 

Pat Helland (who worked closely with Jim Gray and Andreas Reuter who gave us ACID) says it best in his paper “Immutability Changes Everything”:

The truth is the log. The database is a cache of a subset of the log. That cached subset happens to be the latest value of each record and index value from the log.

Let’s look back at the example financial scenario with this definition of data.

Consistency Remix

There are 2 things that bother me about my example. The first is that the entire thing is erased from existence if only the last step fails. The 2nd is that the 2 updates just change the balance without caring what the previous value was.

Problem #1 - Data vs Facts

The insert of the actual transfer record went just fine - at that point the transaction could be considered official but we have to wait for 2 denormalized tables to confirm the same changes. Relational databases are all about normalized data, but quite often when we talk about transactions we are really talking about dual writes of denormalized data. There isn’t any reason a single balance transfer needs to be written in 3 places other than to simplify the read model. It is one event that has multiple effects which we denormalize and write in a single transaction.

This is where the community is shifting its understanding of data. Facts are the source of truth, while data is the sum total of information that can be derived from the facts. To put it in context of our transaction - facts are the records in the redo logs, while the representation of those facts is the data tables. 

So what if the “log” in our application was the single insert of the money transfer? We’ll denormalize the view of that fact into the denormalized balance of Person A and Person B, but if one of those updates fails maybe it’s not right to totally invalidate the fact of the transfer or attempted transfer. If we can safely replay our log to ensure the balances are eventually updated then maybe ROLLBACK is the wrong model here - we could look to record our facts first and then ROLLFORWARD any denormalized downstream effects by replaying them until they succeed. 

You may be thinking “doesn’t this raise the possibility of inconsistent reads until the data is propagated”? Yes, but this is the same problem that relational databases face within an uncommitted transaction - which is handled internally using logs. Reads against the denormalized balance aren’t implicitly trusted, just as Oracle doesn’t trust their internal data files without a check against the undo logs. We can implement a similar pattern in our apps to control the consistency of our data and verify or adjust against the logs as needed. 

This isn’t a pattern I would want to implement everywhere, but in the few cases where transaction-like behavior is actually needed it provides a nice verification layer to ensure that all events have been processed. If you need to manage the potentially inconsistent reads of the log itself you can use a number of different tools from simple caching to lamport clocks or vector clocks. 

It’s up to us - if we have the source facts available in log tables we can project or suppress the publicly available view of that data however our context requires. On a related note see Martin Fowler’s Contextual Validation for some great thoughts about the validity of data and what we allow in the database. Perhaps the record of the attempted transfer is worth writing into our database regardless of whether it is ultimately valid or successful.

Problem #2 - Destructive Writes

We’ve talked a lot about the power of structured logs, and one of the central points is that they must be immutable or unchangeable. Once something has happened it is in the log for good… the only way to get rid of it is to write another log with a compensating action. This is a powerful concept that I’ve come to rely on so much that anytime I see an UPDATE or a DELETE statement I get uneasy. It feels so risky to me now to throw away critical data, yet we are so used to doing just that because ACID guarantees make it seem like a safe operation. Like most developers I have the scars to prove it isn’t safe at all. How many bugs or user errors have we seen where a record was updated or deleted incorrectly and trying to get it back is hard or impossible?

Just because Person A changes their address doesn’t invalidate the fact that they lived in another place before a certain date. Yet it is so ingrained in our old architectural minds that CRUD is normal and UPDATES and DELETES are necessary and harmless. They are fine for derived data, but I believe all critical source data should be modeled as immutable facts first. UPDATE and DELETE the effects of those facts all you want. In my example above I’m calling the balance a denormalized view of the data so an UPDATE could be ok but the statement still looks wrong to me.

Update balance of person A = A-$100

This statement is saying I don’t care what the balance was before, I’m sure it’s ok to just remove $100 from it. Again this seems like a risky behavior that we are used to only because ACID has allowed us to get away with it. Of course most applications would have a check to be sure the previous value was what we expected but this just adds complexity to work around this write after read data hazard. It would be much less error prone if our balance was always generated from the history of the logs/facts. The above statement is not idempotent - it can be executed once and only once. A balance update based on the sum of verified transactions can be done repeatedly and will auto-heal itself in the event something goes wrong. 

There are patterns for snapshotting so you don’t have to read every log from the beginning of time all the time, but this method of deriving denormalized data from source facts is so much safer than the alternative. I believe this strategy is critical if you have a distributed system - concurrent writes to an immutable log that feed into a single balance eliminate several complexities that are introduced by concurrent destructive writes directly to that field. 

Now that I’ve worked with Cassandra for a while and I have implemented these patterns I see that most of my initial fears about eventual consistency were rooted in anti-patterns that ACID had only let me get away with.

Any developer of multi-threaded applications knows the complexity and danger of shared, mutable state. This complexity is at the heart of ACID guarantees and we have been building applications on this foundation for years. If we lose the consistency guarantees we have to also move away from using the database as a container for shared, mutable state. 

What we really should be asking is “what other algorithms accomplish the same net effect?” I’ve found that the patterns to manage eventual consistency also make applications much more resilient, fault-tolerant and ultimately more consistent or correct. It is a complete fallacy that database consistency equals application consistency. Many of us including myself have believed this fallacy and relied on it on for too long… but I’ll write about that will be a separate post.

Wrap Up

Jonas Bonér says “Consistency is an island of safety, but so are immutability and idempotency”. I love this quote and have found it to be true - immutability and idempotency actually can give us back consistency in an inconsistent world. Decades-old principles still apply - structured log storage is not nearly a new concept. When trying to coordinate data or services that are distant or disconnected the tools of immutable logs and idempotent behaviors are invaluable.

It took me a while to wean myself off of reliance on ACID and I was very skeptical of all the voices that were critical of relational databases. The writings/talks of Pat Helland and Jonas Bonér in particular helped me reshape my thinking about what a database should do, and how to build an application around a database that couldn’t hide all the complexities of concurrency from me. With or without a relational database to rely on I would implement most of these concepts at least for any critical path in my application. Relying on the immutable logs of financial events that can be replayed over and over as needed enabled us to build an accurate, consistent and reliable system on top of an eventually consistent database. 

I’d highly recommend watching two great videos by these guys who explain it much better than I could:

Subjective Consistency - Pat Helland

Life Beyond the Illusion of the Present - Jonas Bonér

I think this article is also well worth reading:

Using logs to build a solid data infrastructure (or: why dual writes are a bad idea) - Martin Kleppmann

Back to the Future of ACID: Part 1

Back to the Future of ACID: Part 1

---

Borrowing from ACID Patterns to Tame Eventual Consistency

- Written by Matt Howard

I recently had a discussion on a message board with someone who was looking for ways to implement ACID-like guarantees (Atomic, Consistent, Isolated, Durable) where using an ACID-compliant database wasn't possible. I think that conversation has a much broader appeal - I see the same general question being asked over and over in many different ways and in different contexts. It has more to do with a shift in thinking about data than it does with the details of database behavior. So I thought I’d move the topic over here for the benefit of anyone else who finds themselves in our shoes.

Developers who are used to building apps around traditional relational databases are struggling to adjust to some of the latest tools taking over cloud platforms. Several years ago I was trying to make sense of building a financial system on top of Cassandra - an eventually-consistent database. My question then, and the topic from this recent poster, was “how do I make things behave atomically and consistently without a database to guarantee it?” The example scenario was something like:

1. Insert $100 transfer from person A to person B into a ledger
2. Update balance of person A = balance-$100
3. Update balance of person B = balance+$100

These things have to happen atomically - if any step fails the entire series must be aborted. This used to be something developers didn’t have to think about… wrap the statements in a transaction, send it off to the database and wipe our hands of the complexities that make it work. Now many are finding they have to figure it out for themselves with databases that have abandoned ACID in favor of speed and availability. So how do you maintain data consistency in a distributed or disconnected system? The answers I have found are:

1. You can’t, stop trying… and
2. Follow the patterns they used to implement ACID guarantees in the first place 

Unfortunately most of the answers you find online stop at #1… and leave the conversation at “consistency is overrated - you don’t need it”. While this is true in many circumstances there are critical times when it is necessary. The good news is that there is much more to the story. We’ve just become accustomed to doing things this way because we could get away with it - not necessarily because that is a good way or the only way of maintaining data. In most/many cases there are better alternatives that come right out of the ACID playbook.

Time Travel

To go forward with these new notions of consistency we have to go back a bit to remember how the old model works. This is a big topic that I'm going to distill down to two concepts that I believe make relational databases so reliable:

1. Write-ahead-logs (WAL) - before you actually do something you log the fact that you are about to do it
2. Idempotency - you can take the same action twice (by replaying the logs) without any unwanted side-effects… this is often defined without the word “unwanted” but that is a critical difference 

So let’s return to that atomic transaction above using Oracle as an example. I want to insert a record, then update 2 other records as a single all-or-nothing step. The first thing Oracle will do is generate REDO and UNDO logs before it touches my data. The REDO log is a description of the changes being applied so if the system crashes it can replay those logs to get back to a consistent state once it comes back up. The UNDO log is the opposite - a description of what the data was like before the change, so if the system crashes in the middle of a transaction it can then apply the UNDO logs to make it appear to me that a partial change never happened. UNDO logs are also used to effectively hide uncommitted transactions from concurrent connections.

1. Insert $100 transfer from person A to B into ledger
2. Update balance of person A = -$100
3. Crash / failure / whatever you like

Since we didn’t commit the transaction Oracle will apply our undo logs on recovery to clean up the $100 ledger entry and the $100 debit to person A’s balance.

Note that atomicity is a bit of an illusion. “All-or-nothing” is a display trick that the database does to make it look like nothing happened. From https://docs.oracle.com/cd/B28359_01/server.111/b28310/undo001.htm:

When a ROLLBACK statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction.

The changes “were made” for steps 1 and 2 above. It’s just that Oracle’s read model uses the undo log to hide those changes from other concurrent sessions and it takes compensating action to remove the unwanted effects of those changes in the event something goes wrong.

The same UNDO logs are used to control the consistency of reads for data that is either in the middle of being changed (but not committed) or has been committed but only after a read request was issued.

http://docs.oracle.com/cd/E11882_01/server.112/e40540/consist.htm#BABFDBAJ

The above diagram shows how Oracle hides updates to 2 blocks of data that were committed at time SCN 10024 from an earlier SELECT statement issued at time SCN 10023. It reads the 2 blocks from SCN 10024, sees they are newer than the requested “date” and applies the UNDO logs which revert those 2 blocks of data back to SCN 10006 and SCN 10021.

Note that if you don't fully control the read model then you also lose control over your consistency boundary.

This is a key tenet of micro services that pays off greatly when trying to manage eventual consistency - control your read model by not allowing outside actors to peer into your internal state.

Developers are so used to things appearing as if they never happened on rollback that we make it an absolute requirement, however by adjusting our definition of “never happened” to match Oracle’s definition we gain a lot of flexibility to work in a world of relaxed consistency. We certainly often write details of attempted transactions to our application logs and don't expect a database rollback to erase those logs because application logs aren’t visible to the users. In fact we like to keep those logs so we know something was attempted. The existence of “invalid” data isn't an issue if the application doesn't expose the incorrect effects of that data. Relying on structured logs is a decades-old pattern in computing, and many argue it is rooted in practices dating back millennia. Replaying time-series logs to reconstruct a view of the world is almost inherently idempotent and gives us back much of the consistency control developers are seeking. In Part 2 we’ll look further at what this means and how adjusting our definition of “data” can help us to apply these concepts in our own applications.

Have an Opinion – Part 3

Have an Opinion – Part 3

---

Written by Travis R. Rogers, Director of Software Engineering for Axispoint

This is part three of a 3-part series about the art of the opinion. Have an Opinion – Part 1 provides some definition and justification for this method and Have an Opinion – Part 2 provides a basic set of rules for having an opinion. Opiners, those that have and willingly express opinions, are a special breed and require understanding of their nature in order to expose optimal value so this article discusses some of those traits.

I encourage you to read all of Part 1 and Part 2 but in case you are just interested in the psyche of opiners, I have copied some particularly relevant caveats and provisos into this article.

Truth: There are six different English definitions of Opinion provided by the online Oxford Dictionary. From those, the definition this article refers to is, 
 

“A view or judgment formed about something, not necessarily based on fact or knowledge.”

That’s right, we accept and even expect that people will present opinions “…not necessarily based on fact or knowledge” because having an opinion is a process as well as a destination.

Truth: Opinions, in our world, include ideas, thoughts, points of view and etc. They will all be treated the same.

Truth: To those that know me, some of the rules or guidelines presented in this series will smell strongly of hypocrisy. Admittedly, I struggle to follow the rules but that doesn’t make the rules less valid, it just provides additional (or at least some) evidence that I am human.
 

What to Expect from Opiners

1. Lots of Opinions.

Obvious…but here goes. If you tell people their voice is important, encourage them to use it and hire people because they have an opinion you will be surrounded by opinions about every possible aspect of existence. Oddly enough, prior to Clinton’s famous comment “It depends upon what the meaning of the word ‘is’ is.” I had multiple opportunities to engage in a debate about the definition of “is”. 

Most of the time I enjoy a plethora of opinions but not everyone does, even incessant opiners. On the plus side, there is rarely a time when you go to lunch and everyone says, “I don’t care whatever you want.”

2. Lots of Creativity.

I was looking for synonyms to Opinionated and was a little surprised by the large amount of seemingly negative and close-minded words like biased, inflexible and intransigent. If it hasn’t been made clear in prior articles, in the Axispoint culture having an opinion is different than these negative connotations. A group of people that have an opinion and are able to follow the basic rules of having an opinion (see Part 2) are ultimately very creative and open to other’s creativity.

3. Lots of Questions.

Well, it is one of the rules and also a common trait of technologists.

4. Lots of Truth.

See rule #3 and #4 above. If you ask a question, someone will answer it honestly. Years of experience have led me to adopt a personal guideline, “Don’t ask a question you don’t want to really hear the answer to!” Several years ago I was on vacation and had my hair buzzed because it was hot. When I returned to work I asked someone what they thought of my hair. Their answer, “It’s brutal.” It was the truth…not tactfully put…but the truth. Would I have felt better if they had said something like, “It’s not my favorite for the shape of your face.” Or, “I preferred your hair the way it was before you left for vacation.” Maybe, at least for a few minutes until I deciphered the code.

5. Lots of Confidence.

Some might say, “Lot’s of Arrogance.” Having an opinion is not arrogant in and of itself, but arrogance is a byproduct of not properly assessing the value of an opinion (see rule #1). Confidence is good and is expected when people have their opinions poked, prodded and beaten by equally confident and competent people.

6. Lots of Fun.

Good people interacting to create great solutions is just fun. With the right people and attitude, the environment builds respect and camaraderie and provides opportunities for people to learn, contribute and flourish in ways not available elsewhere. On top of that, who doesn’t love a good debate?

Have an Opinion - Part 2

Have an Opinion - Part 2

---

The Golden Rule

Written by Travis R. Rogers, Director of Software Engineering for Axispoint

This is the second part of a 3-part series about the art of the opinion. Have and Opinion – Part 1 provides some definition and justification for this method while this article provides a basic set of rules for having an opinion. I encourage you to read all of Part 1 but in case you are just interested in the rules I have copied some particularly relevant caveats and provisos into this article.

Truth: There are 6 different English definitions of Opinion provided by the online Oxford Dictionary.  From those, the definition this article refers to is,

“A view or judgment formed about something, not necessarily based on fact or knowledge.”

That’s right, we accept and even expect that people will present opinions “…not necessarily based on fact or knowledge” because having an opinion is a process as well as a destination.

Truth: Opinions, in our world, include ideas, thoughts, points of view and etc. They will all be treated the same.

Truth: To those that know me, some of the rules or guidelines presented in this series will smell strongly of hypocrisy. Admittedly, I struggle to follow the rules but that doesn’t make the rules less valid, it just provides additional (or at least some) evidence that I am human.

The Golden Rule

If you think you know the answer, then say it!

Let me set the stage:

1. A problem presents itself.

2. A meeting is held to discuss the problem.

3. A decision is made.

4. Investment is made towards that decision.

5. A person that participated in the meeting says, “You know, when we were discussing this the other day I thought that…” and out of their mouth comes something they didn’t previously present which turns out to be:

a. An important point that would have changed the decision.

b. Or a better solution to the problem.

c. Etc.

Having an opinion, especially one that is firmly held, and not speaking it in a timely manner is highly frowned upon. This is sometimes referred to as “the biggest sin” within our design process.

The Rest of the Rules

Having and opinion could be considered a form of brainstorming but it’s more than just spouting out whatever is on the top of your mind and some basic expectations need to be understood and managed in order to get the most value.

1. You must be able to honestly assess the value of your own opinion.
This rule allows for the creativity of traditional brainstorming via the portion of the definition that says “..not necessarily based on fact or knowledge.” But, it requires honesty. If you have an opinion that is purely based on gut feel or just an idea that you want to put out there then fire away, but preface it with that information. This way everyone is clear on how to approach the opinion. For example:

Bob: “I strongly believe that we should do X.”

Jan: “Three months ago I worked on a project that had this same set of circumstances. We were unsure what to do so we tested X, Y and Z. Z was the best option because it achieved the goal with the lowest effort.”

Jon: “I have an idea that hasn’t been mentioned but I don’t really have any experience with it, what do you think of F?”

Ann: “I don’t have this specific experience but 20 years of doing this type of work leads me to believe that Y is the best option for these 3 reasons…”

Bob is highly respected and very capable but we initially have no way of knowing how he came to his opinion and how valuable it is therefore it will be challenged (as will/should all the opinions above). As it turns out, it was just an opinion with no facts or specific knowledge to back it up. It also turns out that upon being challenged Bob asked Jan for more detail about her experience, the group identified an inconsistency between the current problem and Jan’s problem of which Jan was not aware. It was eventually decided that X was actually the right path forward for various reasons, the very least of which was Bob’s initial comment.

2. You must be able to properly express your opinion.
This is a very simple set of guidelines, but are probably the hardest to maintain. The first is to be nice.  Don’t raise your voice. Don’t call names (passively or directly). Don’t pound on tables or white boards. Don’t pull rank to shut people up. Don’t talk over others. Etc. ad nauseum.

The second is to be forgiving. Stating an opinion that you know will be challenged by people whose respect you desire is a significant personal risk and eventually someone will raise their voice and/or etc and, within bounds, each of us should be allowed a pass.

3. You must be able to listen to other’s opinions.
Stop reading email. Stop looking at your phone. Stop thinking of your next argument and listen. Listen not for why someone else is wrong but for what they are right about and why they think they have a point. Actively search for the value that is inevitably there. It is each persons responsibility during these conversations to find and piece together the bits of genius.

If you are unable to listen mentally for some reason (bullheadedness?) then give yourself some time away from the meeting to reflect on what you heard and then search for the value. This is critically important and often difficult for myself and others of my opinionated ilk so I often refuse to finalize a decision at a first meeting instead we “sleep on it”. Not only does this provide separation from the stresses of the conversation but also allows the subconscious to process everything that was said. Uncountable times I have walked from a meeting thinking someone was absolutely wrong only to realize later that there was a little bit (or a lot) of genius in the opinion that I had mentally and emotionally blocked.

4. You must be able to listen to other’s opinions about your opinion.
If you give an opinion in a room full of opinionated people, you will be challenged. Gird yourself and then refer back to #2 and #3.

5. You must be able to solicit opinions from others.
A key indicator that someone is not listening is when they are not asking questions. Ask questions, present scenarios, draw diagrams, act things out…whatever. All this in an effort to get information from others instead of making your point. You are not the smartest person in the room and even if you are, someone else in the room has thought of something you haven’t.

6. You must have the ability to change your mind.
It’s that simple, if you can’t change your mind then you don’t have an opinion. You have a fact in your head, in the realm of “The earth is the center of the universe and if you say otherwise then you’ll be placed on house arrest forever.”

It is ok, to present and defend your opinion with confidence and vigor but once you reach the point you believe you are absolutely right about a complex plan/topic then you are failing the group and wasting everyone’s time.


7. You must have the ability to accept a path forward that does not coincide with your opinion.
Debate and discussion cannot go on forever and consensus may never be reached or be valuable. Someone will eventually say “I heard and understood and this is the way we are going” and that way won’t always match your opinion. Simply put, that hurts, but it is a waste of time and energy to constantly rehash old battles or say “I told you so”. This sabotages the process of future problem solving, wastes time and is generally petty. If you want to have a voice than you have to learn to maturely deal with the emotional ding of not getting your way.

8. You must be able to engage in positive verbal conflict.
Open debate or conversation is a form of conflict but it doesn’t have to be negative. Maybe this is a restatement of several rules above but it is worth saying. Negative people have valid and valuable opinions. Negative events (discussions and etc.) might identify valuable plans/solutions, but negative conflict has a limited life. Positive conflict can perpetuate and get better. Conflict is inevitable and always has some value. Positive conflict is invaluable.

9. You must be able to walk away.
If you like being heard and like solving problems most of the time you will walk away from presenting your opinion invigorated and excited even if you didn’t get exactly your way. Regardless of how stubborn I am, if my opinion provides no value but someone else or a group finds an elegant solution to a problem I am elated. But there will be times when you are hurt a little by the process. When that happens…compartmentalize, apply the Vegas principle or whatever but leave it at the door. Remember that these are your friends and colleagues which you spend a large amount of time with and work is fun when you get along…one conversation is not worth a lost friendship.

10. You must be able to apologize.
Recently, I had an opinion about the way something was done and I let it fly. A while later I realized that I had not read something correctly and also had broken several of the rules above (especially #2).  Unfortunately, I had emailed my opinion and cc’d people so of course I had to email an apology and include with all the same people…that’s only fair. If you want a voice it will not always make you proud so be prepared to use that same voice to make amends within the same context and grandiosity as you err.

Summary

The biggest sin is having an idea/opinion/answer and not speaking out but there are a few other rules that keep an opinionated environment from becoming chaos. The 1st segment of this series discuss the virtues of nurturing opinions and the last describes some of they key traits of people that thrive when they opine.

Have an Opinion – Part 1

Have an Opinion – Part 1

---

Written by Travis R. Rogers, Director of Software Engineering for Axispoint

Spend a little time around Axispoint and eventually you’ll hear someone extoll the virtues of “having an opinion”. Having an opinion is required in order to facilitate how we work, this is the first of 3 articles that define what we mean and discusses many of the related dynamics. Part 1 will begin the definition and provide some reasons that this technique is valuable.

Future articles separate from this series will provide specifics on how having an opinion facilitates other parts of our work style and environment (i.e. “Design is a Contact Sport” and “Design is a (benevolent?) Dictatorship”).

Truth: The “someone” mentioned above is often me, which might just be a way to justify my actions. Regardless, having an opinion has long been valued within Axispoint and although pervasive and perpetual; until recently, was more subconscious than manifest. Illogical…I know. This cultural practice, intentional or otherwise, is part of the Axispoint psyche and those with the courage to be heard, have a tendency to thrive. 

Truth: Not everyone considers having an opinion worthwhile and some will argue that the negatives (and there are negatives) outweigh any perceived benefits. I find this concept amusing since having an opinion about the relative value of having an opinion requires that the opinion about opinions is valuable.

Truth: There are 6 different English definitions of Opinion provided by the online Oxford Dictionary. From those, the definition this article refers to is, 
 

“A view or judgment formed about something, not necessarily based on fact or knowledge.”

That’s right, we accept and even expect that people will present opinions “…not necessarily based on fact or knowledge” because having an opinion is a process as well as a destination.

Truth: Opinions, in our world, include ideas, thoughts, points of view and etc. They will all be treated the same.

Truth: To those that know me, some of the rules or guidelines presented in this series will smell strongly of hypocrisy. Admittedly, I struggle to follow the rules but that doesn’t make the rules less valid, it just provides additional (or at least some) evidence that I am human.

Why?

Being surrounded by a bunch of opinionated people that are encouraged to bloviate, sounds like a big hairy free-for-all. That normally doesn’t transpire since traits like respect, honesty, capability and thick skin tend to minimize the anarchy. There is a cost in time, effort and patience that come along with this style but for us, the benefits far outweigh the costs.

1. Training, Education, Experience.

We are consultants and our clients expect us to express opinions defined as:

“A formal statement of advice by an expert on a professional matter.”

Providing well structured, fully thought out and tactfully stated opinions require training and practice. Seeing the way others think and approach solving problems expands each individual’s thought processes and makes us all more aware, respectful and thorough. The world is full of rough edges and stressful situations so having a safer environment to discover which personal and group strategies provide control and positive outcomes prepares people for providing the proper types of input and guidance when dealing directly with our clients. By hearing and understanding other opinions and having to reconcile them with our own, we learn how to listen, ask questions and ultimately understand each other and our clients better.

2. More Options (or Exponential Bits of Genius).

Our clients have imposing barriers that need addressed whether it be time, money, technology, complex dependencies, politics or all of the above. The combination of barriers and their specifics vary by client/project. Plus, clients generally know their domain better than us and have their own highly capable people addressing the issue. So how is it possible that Axispoint provides our clients the necessary leverage to dispel these barriers? There are several reasons but the one relevant to this topic is “Exponential bits of Genius”.

For various reasons it is common that in a group of a several people there is one or maybe two that dominate the process of identifying a solution. Simple math quickly shows the fault in that process. Let’s say there is a a group of 6 people discussing a sticky problem. If each person has 2 uniquely valuable ideas and one person dominates then you get 2 ideas but if everyone contributes, then you get 12 ideas or 600% more ideas. 

600% more ideas sound pretty good, but in the right environment, where multiple people are empowered and capable of contributing, the difference is much greater because each idea has the possibility of reacting with every other idea to make a new uniquely valuable idea. Back to our example, the math is 2^6 or 64 options which is 3200% more bits of genius!

Yeah, I know this is human activity and the result will not really be linear to the number of people/ideas, but the point is still valid. A few opinionated people with a broad cross-section of capabilities and experience working together will provide significantly more options.

3. More Complete Solutions.

It is rare that a single person can think of the best idea and consider all the risks and nuances in any complex problem. It is common however, that different people will focus on different aspects of the same plan, or that they advocate a different plan because of specific risks or challenges obvious to them. Ultimately when multiple people offer various opinions, some way forward has to be selected and will favor some opinions over others. By taking the time to understand the supporting reasons (whether logic or experience) for each opinion, adjustments can be made to optimize the benefit behind some ideas and minimize the risks behind others even when these opinions aren’t primary to the vision driving the plan.

4. Coverage.

It is literally impossible for one person to keep up with the state of all computer technology. Axispoint builds custom software and we approach our projects from a standpoint of being technology agnostic. While we have favorite technologies and techniques that influence us, our agnosticism guarantees that we won’t reject a technology out of hand because it’s not our preferred or most understood path. It is common that prior to our involvement our clients have been advised that they need to scrap existing work and rebuild it using “X”. We believe the primary reason to support a recommendation like this often boils down to the familiarity or expertise a particular vendor/person has with “X” technology. Internally we refer to this as being their hammer as in the adage, “If your only tool is a hammer then every problem looks like a nail”. Unfortunately, what is really happening in some circumstances is that the problem is clearly not a nail and rather than find or learn a more proper tool, the problem is replaced with a nail so that the hammering can commence.

By fostering an environment where people are capable of expressing their opinion, we don’t have to rely on one or two people to keep up with technology. Instead we spread the load which makes for wider and deeper coverage and is easy for Axispoint to bring proper solutions to bear effectively.

5. Consistency.

Our clients typically want our help implementing some manner of differentiation and advantage based on innovation. Additionally, every project has multiple potential paths to success. In fact, some of our projects that appear the same have successfully and properly followed dramatically different paths. There is one thing that every client expects from us on every project…efficiency. A key method of achieving efficiency, is through consistency or

“The quality of achieving a level of performance which does not vary greatly in quality over time.”

Opinionated vocal people, different project/client constraints, technology agnostic, custom software…it sounds a little like a recipe for madness and that efficiency through consistency is unlikely. Admittedly there is no single formula that anyone can possibly apply in the described circumstances. Regardless, Axispoint achieves consistency along with the resultant benefits through a variety of mechanisms and patterns that are empowered by our combined capacity to have an opinion. People at Axispoint at all levels use their voice to identify and leverage patterns that are appropriate to the circumstances. These could be technology patterns, process patterns or some combination, they could be patterns we have learned internally or externally and they can vary in scale from micro-patterns to patterns that almost reach formulaic project solutions. An example of a tried and true pattern that is used in many of our projects is our Hybrid Offshore model.

6. Other.

In a nod towards brevity I will list additional benefits of cultivating opinions and for the moment leave most of the detail to the imagination of the reader.

1. Good Mental Exercise.
2. You have one anyway, might as well voice it.
3. Prepare to Innovate.
   1. Every innovation begins with the phrase “I believe” and the understanding that there is risk in acting on that belief.
4. Garner Support.

   “…I am obliged to say to the American [technologist], ‘This is why you ought to do this’ and then [s]he does it.” 

   1. There is a quote from Prussian General Friedrich Wilhelm von Steubon who helped train George Washington’s troops during the revolutionary war. The quote itself targets American’s but it seems to fit most technologists of today and I think it is relevant,
5. In our business, if you can’t explain the “Why” of something it is hard to gain support.
6. Validate future and on-going plans.
7. Being Involved and Heard is Fulfilling.

From House To Hotel – A Guide to Successful Scaling Code Organization

From House To Hotel – A Guide to Successful Scaling Code Organization

---

How should code be organized in an enterprise application?

By Mike Trzcianowski

Imagine you're a general contractor who has been hired to install a new fridge with an ice-maker at a single-family house.

Just from the outside, you notice that the house is a little strange. All the doors and windows seem to be on one corner of the house. You walk in and notice that the first room has 10 ceiling lights, 15 light switches on the wall and 30 electrical outlets, but otherwise it's empty. The room next to it has 4 sinks, 2 toilet bowls, 1 shower, a garden hose, etc. Another room is full of furniture with beds, sofas, chairs, desks and tables. 

You scratch your head and wonder. Where do you put the fridge? How do you connect the fridge to the outlet in one room and to the water pipe or sink in the other room?

This example illustrates the situation I usually encounter when I start working on an existing code base. The developers have organized the code and assembled in terms of data layer, business layer and UI. It's great, isn’t it?

Now, imagine you scale the same problem from a house to a hotel. You have 200 sinks in one room and 500 light switches in another room. The electrician is installing a new A/C unit but, well, his time is limited, so he hooks it up to the first electrical outlet he finds in the "electrical stuff" room. Then he runs a drainpipe to the first pipe in the "plumbing stuff" room. When he turns the A/C unit on it's a disaster.

Why do software developers do this? There are multiple reasons why this happens. Some of them are:

Reason 1: It’s easy to do organize code into layers but more difficult to organize by function.

A reasonably well-written class can be easily classified as data, business or UI layer. On the other hand, the same class could be used by multiple components and in such case it is more difficult to decide whether it belongs in one, the other, or maybe on its own. In other words, it’s easier to decide whether a piece of code belongs in one of three or four layer buckets, than in an undetermined number of feature buckets.

Reason 2: Developers assume that layer organization is equivalent to project or assembly organization.

That is not usually the case. In web projects, your UI might be a web page, whereas the business logic might be inside of a web service. However, the web service will usually include business and data logic. In 99.9% of the times, you don’t need a separate data layer assembly because you will not be supporting multiple interchangeable databases.

Reason 3: Most code examples and project templates are for simple projects. 

When starting a new project, you might see some folders created automatically for you, such as Controllers, Views, Repositories, etc. This may be sufficient for a small project or component, however, once you start adding multiple features, the basic structure no longer works because you have everything intermingled.

So, how should code be organized in an enterprise application?

Rule 1: Organize by feature and not by layer. 

Imagine you are adding a new shipping feature to an order processing system. If everything is organized by layer, you have to dig through the different classes and decide what you need from the data and business layers. On the other hand, if you organize by feature, you can easily find all the classes for managing orders and products in their respective areas.

The additional benefit, especially in an enterprise system, is that it’s easier for different components to have separate databases or even storage mechanisms. This is important because you can now distribute, scale, or test specific parts of the application without having to deploy the full application.

Rule 2: Separate layers by namespace and not by project or assembly.

It’s much easier and more efficient to deploy a single assembly that includes all the components for a feature, while deploying multiple layer assemblies when you really use only a subset of each. Use assemblies only when the code in each assembly is deployed independently.

Rule 3: Keep it agile. Keep refactoring.

Don’t overthink the organization. You may still begin with a single component with layers separate into folders or namespaces. But as you add different features to your application, you will need to rethink how the code is evolving. Don’t just throw new code into the layer folder. The same principles you apply to a class may be applied to a component. Encapsulate logic that relate to the component and push unrelated logic into separate components or namespaces — just think of the single-responsibility principle, but at a higher level.

In summary, what works well for a simple app, may get you in trouble with an enterprise solution. It’s easy to get complacent and not touch existing code. But that is a trap. You need to rethink the evolution of the application structure as you add more and more components. Having the code organized into layers is better than no organization at all. 

However, this isn’t enough for an enterprise application where components need to be reusable for different areas. Plus, don’t forget to think about the work involved in maintaining the application in the future. It takes effort to come up with a good organization for the code. The time spent now will pay dividends in the future. It’s a lot more difficult to come back to legacy code and figure out how all the classes are related to each other. Instead, organize the code as it is added and provide a visible structure that can be easily seen later without having to dig deep through the code.

Comment below to let us know your thoughts on successful code scaling and to find out more about our software development capabilities.

References and related articles:
“Features and Components” - http://scaledagileframework.com/features-components/
“Mapping software architecture to code” -http://www.codingthearchitecture.com/2013/04/08/mapping_software_architecture_to_code.html
“Package by Feature, not layer” - http://www.javapractices.com/topic/TopicAction.do?Id=205
“Scalable code organization in AngularJS” - https://medium.com/opinionated-angularjs/scalable-code-organization-in-angularjs-9f01b594bf06“Single Responsibility Principle” - https://en.wikipedia.org/wiki/Single_responsibility_principle