All technical projects begin with a plan, or at least we like to think so. More often than not, we tend to start swinging our hammers before we even know where it should be landing. It’s also in our nature to want to make things powerful and intuitive.
In order to achieve this, we form what we feel is a complete thought, and with enough passion, we then act upon that thought and make it so.
If you think about it for a moment, that’s pretty cool!
building with Emotions
What we build is rooted in our emotions. This is key, because understanding where and when to use our emotions, project over project, can quickly determine the outcomes. It can also accelerate projects that follow it if used correctly.
Used incorrectly, with unbalanced emotions, a project can go sideways, up, down, and backwards quickly. This tendency to swing out hammers as builders, without a complete plan, creates what is known as “technical debt” [1]. It can work initially, but don’t let that fool you. If you build too quickly, and don’t look at all of the angles first, you could end up making your software more expensive later, potentially exponentially.
Making Meaning
Like anything we need to do more than once, it’s in our best interests to strategically use our emotions to make meaningful and worthwhile decisions as we go. The difficulty with this process is that it requires prior knowledge. For example, think about these points:
- What are the right questions to be asking?
- What are the decisions that need to be made?
- What is the process of answering and deciding all of these things?
- What order do you do it in?
- How does all of this relate to the programming?
- How can I meaningfully contribute to that progress?
- How do I know if things are going well?
- How do I know if things are not going well?
If you just so happened to be building software, which we are here at CommonPlaces, these are all aspects of planning we strive to achieve.
We believe that Technical Debt is bad for everyone, however, we also understand that over-complicated planning can also be very costly.
We need to plan enough to be effective, so that at the end day the software developers have what they need to hit the ground running, and throughout the process, everyone is confident in the success of the project.
Developer & Customer Satisfaction in Planning – Is it Possible?
A rock solid plan drives not only code velocity, but both developer and customer satisfaction. These are both equally important factors for a successful development process. When you have planning sessions that discuss all the functionality and features that the customer requires, then the lead developers can grasp the full breadth of the project, and make key decisions early to avoid technical debt.
When building a portal or complex website, planning comes into play in a big way. Our next blog post in the series will discuss Drupal Roles and Groups, and will explain why you need to consider these features as part of planning your new portal or website.
References:
