Raise your level of abstraction
I have read articles on model driven development, agile development, use cases, UML, BPML. I have even taken classes in some of them. I have seen so many people trying to find the holy grail of tools and techniques to gather user requirements and model a solution. I have worked at places where some of the techniques were used and you know what? In a lot of cases, the solution and/or applications that were produced were not much better than the places that used none of these techniques. In fact,some of the places used almost no technique at all. They just winged it and their result was not much different than places who do employ advanced modeling techniques. So that begs the question. Why? I think the answer is because the best architects, developers and software teams take a more holistic approach to build a solution and not just a technical one.
Merriam-Webster defines holistic as: "relating to or concerned with wholes or with complete systems rather than with the analysis of, treatment of, or dissection into parts ". To relate this to software development, I think this means as solution providers, we need to take everything into account and that starts with the people who will be using our solution, the environment they work in as well as their emotional perspective of how our solution helps them do their jobs. Are they left with a good feeling when working with the solution we gave them? Do they find it really helps?
As solution providers, we cannot just sit in our ivory towers, getting turned on by geek speak. We cannot be the type of people who think they know best and not try to get into the minds of our users. We have to understand their business and the problem they need solved by our solution. We have to understand them. We have to feel what they feel. We need to understand what they go through on a daily basis using the current system that is not quite cutting it anymore and needs to be replaced. We have to be on the same page with them.
So how do we this? We do this by looking at the environment they work in. We do this by feeling their pain and trying to find those pain points. Before we even architect a solution, we need to know these things. How else can we solve them if we have never taken the time out to find them. A sales man friend of mine once said. "You don't sell a product. You sell a feeling".
A well developed solution, should literally solve the users problem domain as well as leave them with the feeling..."I love using it". the best architects and developers are not the most technically savvy. The best ones are people persons. They are they type who love to help people. They are driven to see a problem and how it affects others and are drawn to help. An organization can hire all the "sharpest talent" in the world but if , as people, this talent is more at home hugging their computer, than they are hugging a person, the organization will get expensive "impressive code and solutions" that help absolutely no one and will probably need to be re-factored or worse, eventually replaced.
We can get all geeky until the cows come home. We can use all the latest and greatest modeling tools but if we cannot make the end users life better then we failed. The solution was not any good. It is supposed to help. If it didn't help anyone. It failed.
This was taken from the The Happy Developer
Add a Comment