On back end, there are 4 phases:
- Insights: which correspond to high level words. This conceptualizes a theory.
- Business logic: as placing the high level words to a platform with metrics and other types of measurements that can fit on our environment. This formulates the framework.
- Domain knowledge: which is understanding how the existing business logic and the new business logic cause and effects it will avail to (i.e. looking at use cases, and so on). This reads the situation.
- Implementation. This tranforms the theory as a concrete deliverable. This reflects the projected need the world needs.
On each phase, both are important, but more important is .
- Insights: A/B testing and metrics are not so important as much as understanding human behavior and basic foundations instead of current/expected trends/needs of the market and their numbers.
- Requirements: Public Relations is not so important as much as the long term goals of clients wanting to embed successfully and effectively their insights into business logic. Features, flexibility, easiness is not so important as clients having more control and easier ability to conceptualize the business logic in the stored framework.
- Domain knowledge: Understanding the full scope of a domain knowledge is not so important as having the ability to know how to change the domain knowledge effectively with the current business logic.
- Implementation: Mastering specific technical skills is not so important as mastering behaviors mentioned in the behavior driven back end manifesto. The rest will flow from that.
Preface
I have not worked too much directly with insights, but this blog shows a lot of insights I have studied myself independently. More over, my previous job did not create insights, as we were serving clients instead of us being a client. At my current workplace, I see people have insights, but it was not a thing I meddled too much besides working behind requirements to implementation. I definitely focus and work most of my time directly on requirements on my current job than on my previous job.
What I am really sad now is the behavior of my current job could have been done better. So here I am, ready to tell my story, as after all, I think I got most of the picture how the company works, and I hope I can collaborate myself better to bring them a better vision and gain support on my vision through others on my end.
The problem
As you can see from the manifesto, you can tell that I work directly with data. When I just worked in my first days of my new job, big chunk of data within the domain knowledge was already transformed in a very flexible way. At that time, the requirements were not written well because the environment they chose to implement the domain knowledge was not one where a client could easily grasp what the business logic looked like unless your daily job was involved on implementing the domain knowledge. They did things that they could have been done easier to grasp for an average client to understand. There was less control for some clients to do more advanced stuff within that domain knowledge. In other words, the business logic did not scale up. Moreover, the environment looked like it was more focused on retaining clients trust than delivering the end results clients really wanted.
An easy adjustment to that was to create new small separate domain knowledge that could fit the requirements of other clients. This allowed flexibility again to meet the client expectations, but now with a more cleaner environment and language that is more easier for clients to grasp the business logic. The pace was slow at the current time because it was more like a side project, but it showed results that were close to the behavior driven back end manifesto. The behavior driven back end manifesto is an ideal project that you will never attain it, but you can always reach it by doing incremental improvements and re-designs of existing domain knowledge. At that time, this domain knowledge pace was very slow to be flexible and to add multiple features like other environments could do. But if you add more development staff, enough that it could meet more features and more resource time to make the infrastructure more robust and efficient, then the business logic would scale up without any hiccups in the requirements to the implementation phase.
So the end of the story was: They saw that the costs and time put on that behavior driven back end manifesto was not ideal because their insights was on metrics and A/B testing and saw that this development did not add a lot of features or flexibility. However, they did not see what good foundations this environment provided and brought to life, no matter how small scale the output of that was (after all, its due nature was more like a side project). There was little to no complaints from the requirements to the implementation channel of the behavior driven back end manifesto and we know what we were doing and where we were going: We were and we knew ahead of time that we could prepare any insights within the back end from our clients.
The proponents of using another tool to meet client insights was due to the flexibility of use and multiple features to use, but scale the business logic up, and I am not sure if it will meet the same expectations as the behavior driven back end manifesto. It may go back again where the requirements are not clear or due to the limitations of the new tool, it is not flexible and its more harder to keep domain logic that changes too often compared to other environments. But the most I am disappointed and irritated is that the side project did not got any value. Due to limited resources, it wasn't capable for the side project to do much, but it tried to attain the ideal behavior driven back end manifesto.
If higher management cannot visualize or conceptualize the reasons behind basic foundations and basic things that make our world more matter, what hope is it left in that direction that can result in arbitrary conclusions this tool or the next development project is better based on metrics and A/B testing? I have seen organizations that at least complimented side end projects that went too scrap and got re-used as a part of a component in the main deliverable.
I am kind of disappointed that things turned that way after so many warnings this side project went through others. There is no forgiveness to me while others keep the same pace of an attitude that reacts of ignorance on the matters that matter the most.
My mission is to shed light of the behavior driven back end manifesto as much as I can. When all fate is lost, its the opportunity to shed light and do the right thing, and I don't feel more right on this opportunity than ever before on doing what is right when others already decided their doubts that this side project had no merits. I was completely depressed and sad for these last days as I could not conceptualize or articulate the decision behind this side project, but not anymore. I am casting my bets on something that will really show, where it will meet expectations one day successfully, no matter what. To put it more simply:
In the midst of winter, I found there was, within me, an invincible summer. And
that makes me happy. For it says that no matter how hard the world
pushes against me, within me, there's something stronger - something
better, pushing right back.
I just want internal cultures to grow and work well together, not only to feel everything is going fine. I don't want companies to learn the A to Z things because people do not do their stuff properly and we have to patch everything together. This is not how things should work. We should always look at the source of the problem.
Bellow, a brief draft of how the behavior driven back end manifesto works:
