On FMforums.com Steven H. Blackwell has an interesting blog entry titled “Unskilled and Unaware”. It basically states that what we don’t know can hurt us. This point of view fits with a challenge that I have frequently used to start off my Devcon presentations on server deployments and disaster recovery strategies, asking the crowd of developers: “We are good developers, but are we good deployers?”
Here’s recent entry in a discussion on the FileMaker TechNet forum:
The developer clearly expresses his frustration with having to deal with non-development issues. But theses issues cannot be ignored; they can actually make or break our solutions and equally as important: our reputations.
Typically we developers focus a lot of our time and skills making the development process efficient and safe so that we can deliver quality code, on-time and within budget. The graphic below shows the typical run of the that process. And we all continue to hone our skills and learn new techniques in this area, to be skilled and aware.
But If we scale the timeline to show the true useful life cycle of our solution we can clearly see that the development is only a small fraction of that life cycle.
Once the solution is deployed it will go through a somewhat random set of events that will affect the performance and stability of the solution. I strongly believe that it is up to us to help anticipate and prepare our clients for those events. What good is a finely crafted solution if it is deployed in such a way that it cannot produce business value because it is unsecured, unstable or under-performing? It would be the ultimate failure of all our work. If we want a long term relationship with our clients we simply cannot ignore the solution and its environment once it is deployed.
The skills required for delivering, analyzing or maintaining a good deployment are skills that are outside of the normal development realm and are often ignored. So what can we do?
Seek out server / deployment / security-related questions on the various forums and see if what is being asked makes sense to you. Test yourself: use those questions as simulators to see how you would solve it. Second, at events such as DevCon or Pause on Error, go to those sessions that are focusing on deployment items, including FileMaker Server configuration. And third, don’t be afraid to ask questions on various forums about these items.
Have questions? You can contact our team directly for more insights. Or, check out our other FileMaker posts to learn more about customizing your solution.
I was expecting this article just to focus on the DevOps side of things, i.e. getting the users to actually use the software/new features, but I see you expanded it to so much more! Developers can easily think that such things are not our problem, but as solution providers it definitely is our problem as a solution is only as good as it is useful. E.g. if the network is down then your client doesn’t have a solution.
I’m not saying we need to be jack-of-all trades, but we do need to manage these situations even if it involves outsourcing to provide a ‘solution’ not just a piece of software.
I have had conversations with other FileMaker developers about why I have such a hardware obsession. Many haven’t seen the need to even run a copy of FileMaker server for their own development, let alone for practice.
I have a server rack in my office where I keep a variety of deployments, OSes and networking hardware on. I know of no other way to look like an expert when I show up at the client’s to make the magic happen.
So glad at least Wim agrees with me.
I could not agree more…
The beauty of it is that we can get a long way with virtual machines to do our testing. But it does take dedication to the the end-to-end thinking that is required to make sure that the value of the solution keeps getting delivered.
Wim, I love this post. It needs to be paid attention to by a lot more people than what currently do.