Agile & Development Methodologies

  • Diagramming Tools – A (Biased) Survey

    Diagramming tools can help you to quickly understand a new project, debug code, visualize and enforce usage patterns, and quickly generate high quality documentation.  All good.  However, not all tools are created equal and there are lots of legacy tools (UML has been around for a while).  I wanted to take a look at what is out there to get a sense for how these tools are evolving.

    Below is a slice if you will through what are some next generation offerings in software development, tools that are trying to do something different, and some well established old-guard tools that everyone has heard of and compares all comers too.

    Code Canvas Example

    Debugger Canvas  Debugger Canvas by Microsoft (see video) is based on Code Canvas which was developed at Microsoft Research in  collaboration with the Code Bubbles folks from Brown.  Debugger Canvas is available to premium Microsoft Visual Studio license holders.  I love how you can view a GUI widget, its documentation, and implementation side by side in one clean view.  The development metaphor is very different from a traditional IDE.

     

  • Code Visibility: one factor of code quality that you shouldn’t forget

    Every developer cares about code quality. But how do you maintain code quality throughout the software development cycle? Readability, modularity, and efficiency all are important factors of writing good code but there isn’t much agreement on the best way to maintain a high level of code quality.

    One factor which is often missed in discussions is code visibility, or making sure your code has a clear structure so that others can easily understand it. (Take a look at the diagram above for some of the difficulties encountered when there is a lack of code visibility).

  • Herding Software Developers

    Managing software developers can be a difficult task, especially when working with an agile team. Changing requirements and priorities combined with a learning and growing team can make even the most experienced managers sweat.

    Similar complex interactions have been studied in a number of fields. Game Theory, Cybernetics, and Chaos Theory all provide inspiration to managers looking to ease communication and improve the performance of a team. These theories along with many others fall into the category of Complex Systems. But as developers we need to be careful when utilizing concepts from other domains or managing developers may become an exercise in herding cats.

  • A Detailed Study on Understanding Code

    Let’s face it; code can be hard to understand. We have all encountered a piece of code that took longer than expected to figure out or was easy to misunderstand. It could be a new library, a coworker’s code, or your own code from 6 month’s ago.

    In a previous post we discuss the importance of taking time to study users in order to get feedback on innovative ideas. We did that to determine how developers understand code and why it can be a challenge.

    </p>

    We asked Open Source developers a number of questions. Two that stood out were their thoughts on the difficulty of understanding their code and what they generally wanted more of in such projects.

    </p>

    The first question we asked Open source developers was if they thought that the code they were working on was challenging to understand. Those using the libraries (API Clients) had a different take than those building the library (Core developers).
  • Making Cool Ideas Happen: Studying Our Users and Software Immigrants

    One of the nice things about being Software Developers, is that it’s really nice to spend our time working on cool ideas:  building out systems that help in situations where no solution currently exists. The problem is that often these cool ideas fail. Yes, using an Agile approach helps significantly, especially when customers/users request features. But often customers don’t realize what problems they need solved or what developers are capable of. Skilled engineers have the opportunity to really push the envelope with new and innovative ideas. The challenge then becomes making sure that these new ideas actually meet a need.

  • New Years Resolutions of a Software Developer

    Happy new year all! With the new year comes a chance to re-invent yourself, and as a software developer I find that it is a great opportunity to reflect on how I can improve my skills in the upcoming months. I have thought about this quite a bit over the last few days and have come up with a list of new years resolutions I intend to follow that will help me, and hopefully others, start the new year off on the right foot.

    Practice and experiment with new languages and frameworks for at least a day a month.

    Keeping up with the latest advancements in the software world can be challenging, especially when working at a fast paced start up. Nevertheless, taking time to investigate new and interesting languages and frameworks benefits not only your career, but may also provide streamlined solutions to problems at work. Having an array of languages and frameworks in your developer’s toolkit allows you to find the best solution to a wide range of problems. Career 2.0: Take Control of Your Life seems like it might be a good place to start investigating this resolution.

  • REST Architecture – Simplified

    Recently, while working on some collaboration functionality for our suite I got a chance to work on a REST (Representational State Transfer) based web server. There are many great resources about REST out there but most of them are quite technical and it took a me a while to get it. So, in this post I am trying to explain in some simple terms what I have understood about REST.

  • Dealing with Complex Code: Where to Start?

    When coding we often spend a significant amount of their time understanding new or unfamiliar code. Attempting to use a new library or fix a bug in a poorly organized component without first fully understanding the code we are working with can cause  headaches. Complex code can often be better understood through the use of diagramming tools (discussed here). However diagrams and other documentation cannot exist in a vacuum and there are tricks to better understand your code before attempting to diagram it.

  • Focusing on Developer Needs: Architectural Design, Understanding, and Documentation

    One of the nice things about launching a tool is the opportunity it allows in talking to our users. Over the last 3+ months we have spent a great deal of time talking to development teams about Architexa, and have gotten a great deal of insight not only into what they like and don’t like about Architexa, but more importantly, what pains they have felt. The consensus is clear: while developers do need to focus on coding on a day-to-day basis, to be successful on a long term they need to worry about the parts of the system that are shared between team members. These worries where what we focused on for the most recent release (v2) or Architexa.

  • Wasting Time With Test Driven Development?

    Many teams are moving to test driven development and very often this a good thing. In a drive towards increased code stability and maintainability, good test cases can be very helpful. But this is not always the case; while working with development teams, most teams seem to have one or more critical problems. It seems that it is easy to do Test Driven Development (TDD) badly – below are five situations that I have seen multiple times.

  • The Waterfall Model is not all bad (and some lessons for agile teams)

    The Waterfall model has become a joke and is pointed to as an way of doing software development poorly. While the approach has a number of limitations, it is helpful in some situations. Understanding these situations can be useful when trying to use an agile development methodolgy to make sure that you do not make critical mistakes.

    During a conversation last week, a team lead told me that he considered Agile and Watefall as being two different approaches with the same result. As a proponent of Agile approaches, I tried to understand his situation and convince him of the benefit of an agile approach. After some discussion, I came to the conclusion that his situation was unique in that it actually benefit from a more rigid approach.

  • Developer responsibility in Agile teams

    Agile DevelopmentAs the hype around Agile Development has been reducing – it has moved from just being a buzz word to a set of principles with teams benefiting from adopting it. However, many teams trying to transition to Agile are still not able to do it successfully.

    Part of the challenge is that a large focus of agile has been about teams being able to respond to change and thus working with multiple iterations while having working code. But the focus on iterations and working code is not enough to do agile successfully. Agile teams need to make sure that the teams collaborate and work together effectively to produce results.