The Art of Engineering
The art in this context refers to the intangible, the illogical, the undefinable, the abstract and the human side of engineering.
Have you ever been presented with two solutions and you know instinctively which is the right one, but you can’t explain it?
Have you ever been faced with an elusive software bug? Instead of systematically narrowing it down and trapping it, you intuitively know where it is. You only have to prove it. Sometimes you don’t have to look for the answer, the answer comes to you.
Have you ever been in-the-zone of software development? So deep into it that you write code as if you are possessed. When the code is done and the kinks are worked out and bugs are fixed, you are actually proud. When it works, it works so quietly and dutifully that everyone soon forgets it’s even there. Months later when you come across the code, you wonder who wrote it because you honestly don’t remember. You wonder if this is what it is like when a composer hears music in his head, when a writer’s words pour out effortlessly or when a basketball player nets all his three point shots.
It is fine to define good practice. It makes sense to churn code in your own branch and only merge when it has been thoroughly tested; to test new items when they are freshly checked-in; to have someone review your code before committing the change; to break down big jobs into smaller tasks; to only work on tasks that are approved for the current sprint; to review code assigned to you every morning before starting your code development; to write unit tests before marking an item done; to not support other groups when you are trying to get a release out, etc. etc.
It is also logical to add hierarchy and structure. We define roles for developers, testers, test leads, scrum masters, architects, supervisors and product managers. We build a system so we can crank out software widgets efficiently.
As we build this mighty machine, don’t forget the human side of the equation. A motivated team having a common vision trumps the best process.
What makes a good team?
What motivates a team member to work hard and do the right thing?
When an engineer chooses to take responsibility for a feature, he becomes accountable for the success of that feature. He takes ownership of that feature. He also takes pride in that feature. When that happens, she is motivated to work hard, to solve problems, to give it all to deliver the feature on time and of the best quality possible. She will be willing to test, to figure out how to collaborate, to get people to review her code and to ensure the build is successful. If he wants his feature to be successful, he will need the product to be successful. He will do what it takes to make that happen.
Feeling empowered, having ones opinion valued and having a supportive environment all contribute to a productive team member.
In contrast, when we define and refine the process, we add steps to the process. We want the steps to be followed. We add rules. Team members point out when rules are broken. We build tools to enforce the rules. We find loop holes in the process. We add more rules…
How do we reconcile the rigid against fluid, the art against science?
Many of today’s for-profit companies create too many hierarchies and rigid structures leaving no room for the art of engineering.
By using an independent consultant, you will see self-motivation and creativity at its best.