Tag: software development

  • Getting Started With a Solution Architecture

    Getting Started With a Solution Architecture

    One of the first questions asked as I start or join a software project is what I think about the solution architecture. This question may either be an attempt to have the current architecture assessed or a first step in building the application. The answer can often be frustrating to the listener as it always begins with a question. Furthermore, there are questions that follow that first one. That does not mean there is no “template” for architecting a solution. However, I think it is important to look at what we are doing in order to take the proper steps.

    Define The Problem

    The most critical factor in creating a solution architecture is not the design of the architecture, it is the solution. Otherwise, you are setting up a classic cart-before-horse approach. There is just too much about a well-designed solution that hinges on the problem you are solving to not focus there first. I once heard it best described as a good architect keeps asking “and then what?” as they listen to someone walk through a problem. The first step is understanding the problem and related processes in detail so you can avoid designing yourself into a corner. A failure to properly understand this point counteracts the skills of even the best architects.

    Requirements and Constraints Drive Solution Architecture

    Everyone likes to start with an “it does everything” approach to define a solution. There is nothing wrong with this. However, a solution architecture that is the best fit requires us to drill deeper. Here are just a few key data points every modern solution needs to address.

    • Who is the Audience?
    • What is the size of the initial user base? (how many users?)
    • How frequently will this be used by the users?
    • What is the expected/useful time frame required to solve the problem?
    • Where does the user experience need to fall between form and function?
    • What sort of data is going to be captured?
    • How long does the data need to be retained?
    • How private or public is the solution and the data? (security concerns)
    • What current technical resources are available?
    • What is the “happy path” and what sort of exceptions might occur?
    • How should the user experience the “happy path” and exceptions?
    • What is the expected interface? (Desktop, mobile, phone, audio, visual, or others)
    • How is this expected to grow in user base, features, and access?

    As you can see, this is a lengthy list. It is also just the beginning. The definition of a good solution architecture includes one that is scalable, maintainable, stable, usable, and understandable. However, it also needs to properly and fully address the problem to be solved. Likewise, there is a context to the problem that needs to be understood as well. As an example, check out the sort of questions a building architect should ask: https://maxablespace.com/questions-an-architect-should-ask-a-client/

    Software Architecture Is Like Building Architecture

    I find the best examples to help understand software design and architecture is to look at building a house. There are a lot of ways to build a house. Therefore, there are a lot of questions to be answered before architecting a plan. The link above provides a list of such questions. Software is at least as complex as a physical building. Thus, it makes sense that we need to answer a lot of questions before designing a software solution.

    There is a lot of context around the solution that impacts architecture much like context impacts a building. Think about building a house on a beach and then think about that same house on a mountainside or uneven ground. Then think about the house in a field of empty acres as compared to the middle of a congested subdivision. Context means a lot when architecting a solution. Therefore a good architect will ask questions and dig deep to understand the context around the desired solution.

    Software Architects are a rare breed. There is only a small percentage of developers that grow into architects for a reason. There is a requirement to be able to fully grasp the business context for a solution and then translate that into the technical architecture. Thus, your best approach to starting a solution architecture is to do your homework and understand the problem to be solved and the proposed solution. Only then can you start on the system architecture.

    Check out this article for some more thoughts on getting started with your project: https://rb-sns.com/RB/blog/planning-and-design/

  • Setting Expectations and Project Success – Three Easy Steps for Improvement

    Setting Expectations and Project Success – Three Easy Steps for Improvement

    We all can use more ways to achieve project success or at least increase its likelihood.  Of course, there are many steps we can take in this effort.  However, few provide the impact of setting expectations and managing them throughout the process.  Here are some ways to help you do precisely that in your next project.

    Concrete Over Vision

    The most significant variance in expectations in my experience comes down to vision.  The end product you envision is not what your customer sees.  Since both of these visions are in someone’s head, we need to get those out and compare notes.  Guessing and assumptions are prime culprits in expectations that are out of sync.

    This is why prototypes, wireframes, and user stories are so important in project success.  These tools give us a way to put down on paper the vision in our heads and resolve any differences.  It can seem redundant to write down something all parties appear to agree on, but that does help avoid assumptions and other communication issues.  I have found that we do not always have the clarification of communication that we think we do.  Putting thought into concrete form helps to alleviate that weakness.

    The Devil in the Details

    I once heard it suggested that software architects get in the habit of asking “and then what?”  This is an excellent approach to drilling down to the required level of detail for setting expectations.  The step to put our vision in a concrete form can lead us to think we have more detail than we do.  I have come across far too many customers that point to a page or application and say that is what they want.  However, as we dig into that example, we find that there are features they want that are not on the screen or assumptions made that are not stated.

    An example of this sort of error is easily seen in the assumptions about how a page works.  There will be menu items and other controls that imply action.  When the result is not adequately shown and defined, then it can lead to mismatched expectations.  The “make it look like this” is a good start.  However, it is only a start.  This starting point needs to be followed up with questions to clarify how every piece of the screen works.  This includes menu items, buttons, tab orders, notifications, validations, and more.  A picture is worth a thousand words and may also hide a thousand function points.

    Avoid Drift

    The third item we need to address is potential drift from our starting point.  A well thought out and thorough design up front can help us set and maintain expectations.  Nevertheless, there are surprises and holes that become apparent in any implementation that can impact that initial design.  These bumps can cause drift and even derail the direction that implementation is headed in.

    This problem is easily solved with regular meetings and updates.  Progress and bumps are addressed in each session along with discussions of variance from the original design.  The end product of this process is that expectations are “tweaked” along the way in concert with design adjustments.  Although there are other reasons to take this approach, I think managing expectations provides the most substantial payoff.

    There are thousands (or more) variables that go into project success.  Fortunately, a lot of what determines that success is how the solution is perceived.  Therefore, the better we are at setting and managing expectations the more likely our odds of success.

  • Coding While Impaired – A Reason For Project Failure Rates

    Coding While Impaired – A Reason For Project Failure Rates

    Every so often you will come across a comparison of drunk driving to trying the same action while sleep deprived.  This usually is surprising to spectators when the lack of sleep is shown to be as bad as consuming a lot of alcohol.  Although developers tend to be comfortable drinking and drinking alcohol, they are far more known for long hours and lack of sleep.  Maybe this correlation can also be extended to the larger than average project failure rates.

    The Caffeine Culture

    I have met very few developers over the years that are not proud of their caffeine consumption.  It is a badge of honor to walk into a late night session with six packs of energy drinks.  This becomes their standard approach to the long hours regularly required of those that chose to code as a career.  The problem is that the long hours are inflicted as much as they are elected.  I have experienced a countless number of projects where the approach to hitting target dates is to cancel time off and extend hours to seventy or more per week.

    The typical attitude is to grab some energy drinks and pour more hours into a project to get it on track.  I have no problem with this approach.  However, I do question those that are surprised by lower quality after these pushes.  You can design and test all you want.  However, a team that is comprised primarily of sleep-deprived members is roughly the equivalent of those same people after an evening of adult beverages.

    Mental Work

    When you consider how much more mental coding is (as compared to driving) the problems become apparent.  You have people that are not at their best mentally doing tasks that require concentration and complex thinking.  Once I started down this road, it seemed evident that these projects would have high amounts of errors and thus failure rates.  The worst part of all this is that those increased errors cause more time to be needed to get tasks done.  That leads to less rest and sleep, which leads to more errors.  Thus, a death march is born.

    The amusing thing is that many companies have policies that go as far as terminating those that show up for work inebriated.  Yet, they have no problem demanding the long hours that can lead to the same mental state.

    A Different Path

    There are some instances where the long hours come from poor planning or management.  Unfortunately, many of the situations arise from heavy competition, low budgets, and the related tight deadlines.  You may argue that means that team leaders are left with no choice.  I would say otherwise.

    When you look at productivity curves for the average human, you see a drop off as the day gets “too long.” Studies show the length of a comfortable (and productive) workday varies from worker to worker.  Nevertheless, we can work with averages and observation.

    I recommend that adding hours and pushing for longer work weeks be done in an incremental way.  Ease your way into it earlier in a project if it looks like it will be needed.  You can then closely observe the developers and bug rates to see how things deteriorate.  At some point, there will be a diminishing return that makes long hours not only useless but detrimental.  Once you have that hard limit, you are better served to add resources or accepting slipped dates.

    Developers may like to be “edgy” by embracing sleep loss and long hours.  However, this is not a productive approach to software.  Maybe treating them as imperfect humans will help improve project failure rates.