Dropping The “I” From Interfaces

Thursday, 28 April 2011 03:30 Last Updated on Thursday, 28 April 2011 03:34 Written by Lee Brandt 0 Comments

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:

4 Characteristics Of Every Great Developer

Monday, 25 April 2011 17:27 Last Updated on Monday, 25 April 2011 17:57 Written by AdventureTech 0 Comments

At AdventureTech, we spend time carefully fostering what we refer to as "a community of developers for developers". While it might sound like an altruistic endeavor to allow local talent to congregate and collaborate, we believe it’s an essential component of every successful software development project. But there’s something in that picture that needs explaining and it speaks to the very reason we seek out excellence in Kansas City:

NOT ALL DEVELOPERS ARE CREATED EQUALLY!

With that in mind, let's take a look at 4 Characteristics Of Every Great Developer. This isn't meant to be an exhaustive list, but these characteristics are ones that are critical to successful software development projects.

1. Pure technical excellence. This one kinda goes without saying, but any great developer has extremely strong technical acumen.

2. Be a good systems thinker with the ability to understand how technology fits with business needs and knowing how to deliver value AND software.

3. Be a strong educator. When confronted by users “not getting it,” a good developer takes the time to explain choices and options in technology. Software development is truly a learning culture and placing clients within that team spirit affords the highest possible business value.

4. Strong written and verbal communication skills. We saved the best for last and want to expand on this topic because we believe it is increasingly important and not discussed enough in the developer community.

At AdventureTech, we believe it’s important to speak directly to the traditional criticism surrounding the lowered expectation levels for communication skills in IT. While below average interpersonal skills are not unique to IT, we believe they lead directly to antagonistic client relationships, misunderstood software requirements and ultimately delayed projects. Stressful communication environments quickly erode customer confidence and can provoke the need for intermediaries. Business analysts, for example, are often simply replacement ambassadors to this forced need for mediation and translation.

Forcing the developer/client relationship into the realm of signed and sealed paperwork does not mitigate this antagonism either. We believe it only exacerbates it. Face-to-face collaboration is critical to project success and breakdowns in communication should be addressed directly and personably. When done correctly, the end result is successful, collaborative software that meets the needs of the client.

Have you ever sent an email or instant message to a client where the tone or intent of your message was misinterpreted? Developers who choose email or instant messaging as preferred methods for communication run an increased risk of miscommunication. While that preference might be appropriate for developer-to-developer interaction, we prefer face-to-face or phone calls when collaborating with a client. Email carries with it an inherent danger of allowing people to be braver (and less personable) than they otherwise would be face-to-face.

Additionally, blogging, writing articles, and speaking engagments are invaluable ways to stand out from the crowd of technical excellence. We not only hire educators and public speakers; we also encourage every developer to have their own personal blog and to contribute to the AdventureTech blog.

Clearly, everyone has different levels of proficiency when it comes to written and verbal skills…and that's OK. The only way to get better is to continue to fine tune these skillsets (just as you do your technical proficiencies) and seek out feedback on how to improve from people you trust and respect.

Those in our industry that do will undoubtedly evolve from good developers….to great ones. And that's GREAT for everyone involved.

What do you think? What have you done to improve your communication skills? What other characteristics do you think are important to becoming a great developer?

Did you like this? Share it:

Open Mouth, Insert Software Toolbox

Monday, 25 April 2011 11:42 Last Updated on Wednesday, 27 April 2011 10:34 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:

Breaking the rules

Thursday, 21 April 2011 10:49 Last Updated on Thursday, 21 April 2011 11:08 Written by Brian Wigfield 1 Comment

Scenario 1 – You approach a 4 way stop sign, with exceptional visibility in all directions. You have to decide if you will roll through the stop sign, or be a ‘good driver’ and come to a full stop. Since you see no benefit in fully stopping you decide to roll on through. As you drive on a motorcycle officer pops out from behind a bush and writes you a ticket for not complying with the law.

Scenario 2 – You need to finish a new feature on a project, so evaluating the design options and impact of them. You can either follow the standard approach that your team uses or save half the time and implement it in a much simpler way. After realizing half the effort for the same effect is the best value for the customer you decide to use the simple implementation. As you finish up and commit your changes into source control, the commit notification alerts the resident ‘architect’ and they scold you for not following standards.

The point I am trying to convey is that rules/standards should only be in place to help people that need guidance, either from a lack of knowledge, or lack of a clear choice. Unfortunately the inflexible nature from the bodies of governance stem from a lack of trust. If you don’t have trust in your developers decisions making capabilities then you have a broken system, and your rules are more constraining then they are helpful.

To sum it up in one line, if you are familiar with the Serenity Prayer then this format might sound familiar…

Grant me the serenity to follow the rules, courage to defy the rules , and the wisdom to know when to do which.

Did you like this? Share it:

Modern Day Software Development: “Embracing Change” – Part 2 of 2

Wednesday, 20 April 2011 12:47 Last Updated on Friday, 29 April 2011 12:37 Written by AdventureTech 0 Comments

Last week we wrote Part 1 of our 2-part series on the role change plays in Modern Software Development. If you haven't read it yet, you can do so here: Modern Day Software Development: "Making Change Difficult".

At AdventureTech, we realize that the only constant in software development is change. Because we have a full and deep understanding the role change plays in the software development process, we have fully embraced another common approach to managing software development: AGILE.

Defining Waste

Dictionary.com defines waste as "a useless consumption or expenditure" or even better "a use without adequate return". There is no better example of that than large upfront requirements gathering efforts with the myth of locking down all requirements early on.

Companies claiming to be agile espousing this type of methodology are simply being dishonest with themselves and their customers about who and what they are. The simple and honest reality is that all requirements for a software development effort of any substantive size simply cannot be known upfront.

In an agile world, decisions are made later rather than sooner. The idea behind putting off decision-making until later is that you will have more clarity into what you are building than you do early on. In Lean Software Development, An Agile Toolkit, Mary and Tom Poppendieck describe a concept of waiting until “the last responsible moment” to make decisions. It is at that time that the most data is available to make an informed and educated decision instead of a "guesstimate".

With that in mind, AdventureTech embraces a methodology that breaks a single piece of software into several small functional pieces of software (features) that together make up the end product. We then work toward building each software feature and delivering it to the client "piece by piece", and allowing them to see working software early and often vs. late and all-at-once.

This approach keeps us from breaking out detailed requirements that may never even be built in the long run. Most software developers have seen projects with heavy, upfront requirements phases where as much as 50% of those requirements specified in the beginning never even see the light of day. If that's not waste, we don't know what is!

Change Management

Another common practice for companies not practicing agile is to have large, formal, documentation-heavy change control processes. Software vendors put these processes in place to limit the amount of change clients are allowed once the build effort has begun thereby limiting their risk (and protecting their margins).

At AdventureTech, we embrace a process that allows change but makes it visible to the client. What that means in laymen's terms is that we believe in putting our customers in charge of what we build and how much it costs by the decisions we make together.

Close collaboration with our customers is at the core of a successful agile project. Gone are the days when software developers sequester themselves away from the "distraction of customer interaction" so they can get some "real work" done. In the agile model, the customer and the software developer form a new entity….a TEAM dedicated to buildling software. This model is extremely heavy on trust and visibility with the goal of succeeding together.

While change is much easier in an agile world, that doesn't mean it is not visible or that we are not responsible as a team for the decisions we make. When requirements are changing/growing in an agile project, a good software developer will make that visible to their customer. This allows customers to make whatever course corrections are necessary based on their specific constraints (i.e. time, money, specifications).

Conclusion

Every day, more and more companies are realizing that building software is not like other industries. While nailing down requirements like blueprints for a construction project is possible, it's not the best way to build software in today's world.

According to the Standish Report surveys (1994-2009), 68% of software projects are NOT successful (over time, over budget and/or lacking critical features). The software development status quo is not working and does not deserve to be replicated.

At AdventureTech, we are here to help you learn why agile makes sense for your next software development project and why developing a long term relationship with us will help meet your custom software needs.

If you have questions about agile, leave a comment on this blog or call us today!

Did you like this? Share it:

Dropping The “I” From Interfaces

Use It

Lose It

4 Characteristics Of Every Great Developer

Open Mouth, Insert Software Toolbox

Breaking the rules

Modern Day Software Development: “Embracing Change” – Part 2 of 2

Defining Waste

Change Management

Conclusion

Connect With Us

Contact Us

Upcoming events

Recent Blog Articles

Blog Categories

Recent tweets