My AdventureTech Experience: A Post From “The New Guy”

Tuesday, 31 January 2012 13:37 Written by AdventureTech 2 Comments

Post written by Joseph Davis, Web Application Developer at AdventureTech, AKA "The New Guy"

I first came in contact with AdventureTech in September of 2011. A good friend of mine, Donald Rossberg, had been attending a local business networking event where he met and became acquainted with Brett Gibson, one of the owners of AdventureTech, who was also attending the event. When Donald found out I was passively seeking a new opportunity he arranged a lunch meeting for the three of us so I could meet Brett.

Brett was a very talkative and friendly fellow. One thing that immediately stood out to me in his conversation was his deep interest and understanding of agile development principles. I could tell from the depth of examples he spoke of that, to him and to AdventureTech, “agile” wasn’t just some buzz word they adopted for a season. Instead, it was something they had successfully implemented, that they believed deeply in, and that they had enhanced through multiple experiences with clients.

Some time later I ended up in another lunch meeting, this time with several of AdventureTech’s developers, including Phil Ledgerwood, Troy Tuttle, Lee Brandt, and Brian Moon. I was prepared for a technical drilling as is common with many panel interviews I’ve been through in the past. Instead it seemed they were more interested in telling me about themselves as a company, what they were all working on and what tools they were using in their various projects.

They spoke of Inversion of control containers, object-relational mapping tools, test driven development, and other design and development patterns. Many of these were tools and practices that I had read about and of which I had a fair level of theoretical understanding but had not had the opportunity to put into practice in a professional work environment. The prospect of doing so was very appealing to me.

Until just recently, the team of developers at AdventureTech was composed entirely of very experienced senior level developers, many of whom are involved in the community and give talks at development conferences. Such was their culture and the nature of their team. Now they have begun bringing on some younger developers with the intent of molding the next generation of senior level industry leaders in Kansas City.

They aren’t looking for developers who already know it all, but instead they want people with an aptitude and thirst for learning along with good communication skills. One thing I heard a number of times during the interview process was: “How to write good code? That’s easy to teach. How to teach a person to have good communication skills… that’s something they should have learned in kindergarten."

I’ve been with the team for about a month now and am pleased to report that it is turning out to be everything I was hoping for. Many of the other guys on the team have titles on their business cards like “Software Practice Coach”, “Software Process Coach”, and “Developer Mentor”. I find myself in a place where learning is fostered and supported, and I’m picking up many new things each day. I feel empowered in this environment to be the best I can be and I’m very excited about the future of my career.

In addition to fostering learning and encouraging the use of new tools and technologies, AdventureTech also strives to create a compelling work environment and benefits package that will draw the best developers around. Apart from very competitive compensation and medical benefits, AdventureTech also provides an education and equipment budget so developers can stay sharp, and an extremely generous amount of Paid Time Off that I have only seen matched by some companies for their employees with decades of tenure.

Although I’m still fairly young in my career, I have been through several jobs looking for a place that had everything I was looking for. I’ve finally found that place and I’m proud to be a team member at AdventureTech.

Did you like this? Share it:

Lean & Agile : A Panel Discussion

Thursday, 25 August 2011 13:02 Written by AdventureTech 2 Comments

Today we have short Q&A about agile practices with out esteemed guests Winston Churchill, Albert Einstein, Mark Twain, Martin Luther King, Jr, Gandhi, Bruce Lee, & Franklin D. Roosevelt.

Question: Why do you believe there is benefits in building & watching metrics and then projecting dates versus utilizing pre-defined project dates?

Churchill: The farther backward you can look, the farther forward you are likely to see.

Albert Einstein: A man should look for what is, and not for what he thinks should be.

Question: Is this because full discovery early on is hard to achieve?

Martin Luther King, Jr.: Everything that we see is a shadow cast by that which we do not see.

Albert Einstein: Occurrences in this domain are beyond the reach of exact prediction because of the variety of factors in operation, not because of any lack of order in nature.

Question: The what did you tell your project manager the last time he asked you for an accurate estimate?

Gandhi: I do not want to foresee the future. I am concerned with taking care of the present. God has given me no control over the moment following.

Mark Twain: I was gratified to be able to answer promptly, and I did. I said I didn't know.

Question: Some managers like to create their own artificial estimates to fit their plans, does this work out well in some cases?

Albert Einstein: No problem can be solved from the same level of consciousness that created it.

Mark Twain: Get your facts first, then you can distort them as you please.

Question: But wouldn’t it be fair to say that without a estimate to hold somebody to, that the work item will not be completed in a timely manner.

Bruce Lee: Notice that the stiffest tree is most easily cracked, while the bamboo or willow survives by bending with the wind.

Question: If there are shortcomings in the waterfall methodology, should those just be addressed in the methodology instead of creating entire new development method?

Albert Einstein: Any intelligent fool can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction.

Question: Do you believe in following Scrum as prescribed or do you believe “Scrum But” is acceptable?

Bruce Lee: Learn the principle, abide by the principle, and dissolve the principle. In short, enter a mold without being caged in it. Obey the principle without being bound by it.

Franklin D. Roosevelt: One thing is sure. We have to do something. We have to do the best we know how at the moment… If it doesn't turn out right, we can modify it as we go along.

Question: What would attract a team to using an Agile approach with a loose definition of procedure such as KanBan or “Scrum But”

Churchill: To improve is to change; to be perfect is to change often.

Bruce Lee: All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns.

Gandhi: Constant development is the law of life, and a man who always tries to maintain his dogmas in order to appear consistent drives himself into a false position.

Question: If you have gathered metrics using an Agile approach and your manager demands you to complete a feature in a timespan that your metrics say is not possible, how do handle a response telling them that?

Churchill: The truth is incontrovertible, malice may attack it, ignorance may deride it, but in the end; there it is.

Mark Twain: Let us make a special effort to stop communicating with each other, so we can have some conversation.

Question: It is popular to display a large visual task board so that the team is transparent to anybody interested, why is this information important to be constantly available?

Churchill: A lie gets halfway around the world before the truth has a chance to get its pants on.

Gandhi: An error does not become truth by reason of multiplied propagation, nor does truth become error because nobody sees it.

Question: When starting a new project do you like to create detailed documentation before hand to make development easier?

Franklin D. Roosevelt: Are you laboring under the impression that I read these memoranda of yours? I can't even lift them.

Question: Ok so you may not like a lot of documentation but how can you get started with none?

Martin Luther King, Jr.: You don't have to see the whole staircase, just take the first step.

Franklin D. Roosevelt: There are many ways of going forward, but only one way of standing still.

Bruce Lee: Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.

Question: Having removed so many potential roles and overhead in a development team, should people in those roles be in fear of losing their job?

Franklin D. Roosevelt: The only thing we have to fear is fear itself.

Did you like this? Share it:

Now Or Later: You Must Decide How To Manage Software Project Risk

Monday, 25 July 2011 15:16 Written by AdventureTech 3 Comments

Post written by Troy Tuttle, Project Leader and Software Process Coach at AdventureTech

Risk management is nothing new to the project management community. But in software projects, the traditional approaches to managing risk are far from ideal. Traditionally, we have produced project documents with nice-looking risk matrices that are neatly categorized by severity and impact. This is nice to look at, but how does it help us manage real project risk? We seem to be good at identifying risk, but we give little or no guidance to project stakeholders on how to make decisions based on this information.

In software projects, effective risk management is about the process of making decisions—specifically, deciding the optimal time to execute a decision. The Lean software movement provides us with much better guidance in the form of principles and decision frameworks.

Take, for example, starting a large software project at your company. How do we insure we are not throwing this money away? In a traditional software project, we would come up with a “Grand Plan” that represents the project from A to Z and we would present that to decision makers for funding approval. With funding secured, we start that project boulder rolling down the hill.

When will we know we are building the right thing?

In this Grand Plan approach, we do not typically know until the very end, when the money is all spent. There is no actionable risk mitigation.

Defer Commitments
Grand Plan projects have little opportunity to manage risk along the way because most or all the the commitments are made at the beginning. For example, if we estimate our project cost to be $1 million, we secured that much funding from the overall budget and committed it all to the project at the beginning. What if we changed our strategy and decision making process? Would we better manage financial risk if we fund the first phase, say $200,000, then decide if it would be worth spending more? If so, then we are deferring the commitment of our entire funding amount until we know the project is succeeding.

Think about the same problem in our specifications. A typical Grand Plan will specify the product in total, to a high degree of detail. If we apply a preference to defer commitments in our specifications, what would our project plans look like? They would be a lot smaller, take less time to generate, and would be more meaningful. Instead of detailing precise requirements months in advance, we can defer that commitment until we have better information about the marketplace, our team, or the product itself.

Real Options
Real Options, as applied to software development, gives us a nice decision framework for determining when to defer commitments. The model is described as:

Options have value.
Options expire.
Never commit early unless you know why.

This approach is not complicated, but it has big implications. For many organizations, better risk management could save precious project funds. It could also be the difference between the next great product and something much less useful.

What do you think? How do you handle risk on projects?

Did you like this? Share it:

Dropping The “I” From Interfaces

Thursday, 28 April 2011 03:30 Written by Lee Brandt 0 Comments

Image via Wikipedia

This is not really disruptive. It’s not even a new idea. This has been blogged about before. But one thing that I think seems to get missed is the fact that that “I” maybe keeping developers from understanding the real power of interfaces.

The way that interfaces generally get used is the “I to a type” convention. So I might have an IAuthenticationService and an AuthenticationService, or IUserRepository and UserRepository. Unfortunately, the implementation class doesn’t tell us anything about what makes him an implementation, let alone what sort of implementation. Developers begin to lose sight of the fact that the interface is the contract that everyone agrees on, and the class is an implementation of that contract. Now lots of developers know this theoretically, because it’s been beaten into their heads. It’s memorization. And you might be okay all you life just memorizing that. But I think it’s better to crystalize in your head what interfaces bring to the game. There are two suggestions floating around about what to do with the “I” in interfaces:

Use It

Some folks suggest using it as a proper noun followed by a verb to almost make a declaration of what this contract you’re about to build is for. For instance, if you are making a service that reads files from the file system, you might call your interface IReadFiles, or a calendaring service might be called ISetAppointments. This is fine, but I think it feels uncomfortable to name implementations. The IReadFiles is implemented by the FileSystemReadFiles class or it is completely removed with FileSystemFileReader class.

Lose It

The other school of thought, and the one I favor and have been practicing whenever I can for the last two years or so, is to remove the “I” completely. So my IAuthenticationService becomes AuthenticationService. This has three distinct advantages: I am now forced to name my implementation something meaningful like FormsAuthenticationService. When I am using the interface in my consuming code, it has no inkling from the name that this is an interface (which is the way you should use interfaces. Finally, it can become very clear to programmers what the Interface brings to the game. The Interface is a Generic AuthenticationService it does certain things somehow. The implementation(s) are actually more clearly defined and help developers understand how and when to use different implementations of an interface. Sometimes, just understanding that you can have multiple implementations is a breakthrough for some programmers.

I know this is the programmers last Hungarian Notation Woobee and developers don’t want to let go. But on your next small project, try dropping the “I” from your interfaces and naming your implementations with meaningful names and see how it feels. In the words of Tony Toni Tone, it “sure feels good to me”.

Did you like this? Share it:

Open Mouth, Insert Software Toolbox

Monday, 25 April 2011 11:42 Written by Troy Tuttle 0 Comments

Image via Wikipedia

So often we hear the phrase, “I have many tools in my software development toolbox, and I like to use the correct tool for the job.” It sounds good. It appears to be a responsible approach. After all, why wouldn’t we want someone to have multiple tools at their disposal?

The whole toolbox metaphor is fine on the surface. My problem with it stems from the incidentals in the discussion. In my experience, most people who reference having a “software toolbox” are really hiding from a more direct questioning or discussion of specific practices or methods. Instead of advocating for those methods they believe work, or more importantly, listening to others advocate for their methods, many in our field throw up the “toolbox” as a defense mechanism. It makes for a clean exit too. The problem is this mechanism limits learning for everyone involved. The “software toolbox” is a conversation ender, not a conversation starter.

With that said, I am going to put my toolbox where my mouth is.

First, my obligatory disclaimer: Individual results will likely vary. Past performance does not guarantee future success. Your specific context and corporate culture are critical factors when deciding which tools are best for you. This is not intended as a comprehensive list.

Troy’s State-of-the-Art Software Toolbox:

Small Iterative Development Cycles: Software work is knowledge based. Knowledge in software is best improved by frequent feedback cycles. Early information feedback allows the team and customer to learn and improve at a much faster rate than when iterative approaches are not used.
Source: Extreme Programming, Scrum
Explicit Work-In-Progress Limits: Even when working iteratively, teams will often have too much WIP. Ever observe a Scrum team start every single user story by the first day? I have, and without an explicit policy limiting work-in-progress, teams and managers will try to push too much work into the system. WIP limits allow a team to begin finishing work instead of starting more work. Team context switching is minimized, giving the team the opportunity to improve quality.
Source: Kanban for software
Just-In-Time Planning: Plan just for what you can do, and nothing more. There is no waterfall-style comprehensive requirements document with this approach. Nor is it the heavy backlog grooming practices frequently seen in some Agile teams where user stories are analyzed and specified in detail months before they are implemented. Just-in-time planning also means no commitment-based time-boxed iterations. Optimal planning occurs when the the team is provided with the best thing to work on next, no more and no less.
Source: Kanban for software
High Discipline, Low Ceremony Engineering Practices: Emphasize practices that encourage collaboration and short feedback cycles. TDD/BDD and a continuous integration server are a great start. After-the-fact, formal code reviews are typically too late to add anything other than rework. Code metrics are fine, but be careful what you measure. Are your code metrics making the code easier to understand and change, or are you happy just to apply “standards” to your code? Covering code with tests is a good thing. But higher code coverage doesn’t automatically mean your code base is functioning the way your customer wants.
Source: Extreme Programming
Kaizen: Continuous improvement may come from inspect and adapt, PDCA, or other methods. It doesn’t matter if you prefer one over the other as long as you build an information feedback loop into your process. At the basic level, provide enough oxygen to the team to reflect, share ideas, and improve. Some teams may require regularly scheduled retrospectives, others may perform mini retrospectives or spontaneous Kaizen events during the project.
Source: Extreme Programming, Scrum, Kanban for software

I’m hoping this is valuable information for you. This is my toolbox, and these are some of the more valuable tools to me. If I show you mine, will you show me yours?

Will these work for you? I don’t know, that’s for you to decide. I just know that they work for me today. If I were a part of a brand new software team tomorrow, this is where I would start our discussion. And hopefully we grow to an even better place.

“Merely having an open mind is nothing: the object of opening the mind, as of opening the mouth, is to shut it again on something solid.” — G. K. Chesterton

Did you like this? Share it:

Category: Consultant blogs

My AdventureTech Experience: A Post From “The New Guy”

Lean & Agile : A Panel Discussion

Question: Why do you believe there is benefits in building & watching metrics and then projecting dates versus utilizing pre-defined project dates?

Question: Is this because full discovery early on is hard to achieve?

Question: The what did you tell your project manager the last time he asked you for an accurate estimate?

Question: Some managers like to create their own artificial estimates to fit their plans, does this work out well in some cases?

Question: But wouldn’t it be fair to say that without a estimate to hold somebody to, that the work item will not be completed in a timely manner.

Question: If there are shortcomings in the waterfall methodology, should those just be addressed in the methodology instead of creating entire new development method?

Question: Do you believe in following Scrum as prescribed or do you believe “Scrum But” is acceptable?

Question: What would attract a team to using an Agile approach with a loose definition of procedure such as KanBan or “Scrum But”

Question: If you have gathered metrics using an Agile approach and your manager demands you to complete a feature in a timespan that your metrics say is not possible, how do handle a response telling them that?

Question: It is popular to display a large visual task board so that the team is transparent to anybody interested, why is this information important to be constantly available?

Question: When starting a new project do you like to create detailed documentation before hand to make development easier?

Question: Ok so you may not like a lot of documentation but how can you get started with none?

Question: Having removed so many potential roles and overhead in a development team, should people in those roles be in fear of losing their job?

Now Or Later: You Must Decide How To Manage Software Project Risk

Dropping The “I” From Interfaces

Use It

Lose It

Open Mouth, Insert Software Toolbox

Connect With Us

Contact Us

Upcoming events

Recent Blog Articles

Blog Categories

Recent tweets