kyle shank.

    2010/9/14

  1. What does this software do?

    If you can’t fully answer this simple question then your software project is in trouble.  A clear list of requirements should always be on hand and easily referenced.

    The truth is that the vast majority of software endeavors don’t document anything at all.  If you can’t clearly state what your software does then you should race to find the right answer.

    2. 2010/9/12

  2. Visualizing Software

    There is no easy way to watch a piece of software being built.

    Developers and clients both have a problem of determining where they are at within a software process.  Project management tools like Pivotal Tracker help developers keep track of their progress.  Clients usually have little to no view of the development process beyond a bug tracking system.  Neither is ideal.

    Last week a thought hit me: What if building software was more like building a skyscraper?

    Unpacking that thought further: What if there was a common view of the software process?  Something everyone can understand.

    I imagined a literal interpretation of this idea: an image of a skyscraper being built that represents the software development process.  Floors represent the various tasks and work to be done.  Workers (developers) can be seen as they spend time completing floors.  Watch the building go up and always have a sense of where things are.

    There are a couple of giant pitfalls in communication that I think this kind of idea can help mitigate:

    • Clearly showing that additional features mean a larger building is being built.  The larger the building the further that deadline will have to be pushed.
    • Show that sometimes work is being done to repair existing floors.  Bugs and maintenance never seem to be clearly enumerated in the minds of project stakeholders or in schedules.
    • Reveal major changes.  Sometimes features require a wholesale rewrite or replacement of a main part of the foundation.  These things always require more time.  This skyscraper metaphor may be the right way to show how major certain request for features are.
    • Time affects the severity of change.  A new feature or request at the beginning of the process doesn’t cost as much as one at the end.  This needs to be much more clear to both clients and developers.

    Some of this stuff may seem obvious but developing someone else’s abstract idea is always harder than you think.  We need better ideas and tools to keep everyone on the same page. 

    Software development is largely a communication problem.  Writing code is easy.  Setting and meeting client expectations on time and on budget is hard.

bio.



Kyle Shank, 26, is a software consultant at Reactualize and lives in the greater Boston area. He has worked within the software group at IBM in Massachusetts, North Carolina and Zurich, Switzerland. In 2005 he co-founded the first open source Ruby on Rails specific IDE RadRails based on Eclipse. Kyle graduated from the Rochester Institute of Technology in 2007 with a bachelors degree in Software Engineering.

reactualize (my consulting company)
flickr
twitter
github