I never knew I had it. Then I worked at a company where I saw more senior people who had it too. I knew it was a great help in the software design process, but it was just unquantifiable.
"Software Concept Design & Modelling is all about understanding the requirements and designing the concepts around it, so that what we build as software makes sense as a whole, and provides value to the end user."
Sounds like meaningless jargon?. Not really. And to explain this in more detail, I will br providing concrete real-world examples of where this was done, and it provided immense value to the software development process.
"Understanding Software Concept Design is equivalent to understand the basic rules which make stable software. Such software has less entropy than others. Honing such skills is essential to make software development a repeatable success in the Enterprise."
But right now, I just want to pique your interest. What do these words really mean? - It means that, often, we fudge software design badly because we lose sight of what is really supposed to be built by using big words, or confusing the hell out of ourselves. In such situations, development either comes to a stand still, or worse, something gets built which turns out to be totally useless later.
The field of software concept design is not about technology specifics, or even domain specifics. It is about how we organize the concepts around a solution to ease the technical design. Requirements tell us what the user needs, Technical Design tells us how to implement a solution. SCD comes right in between, and it shows us how to effectively translate the requirements into a technical design.
This can totally change the direction of a software project:
1) Turns out that what we were discussing the past few weeks was of no use because as a complete solution, this makes no sense.
2) Somewhere along the line, we forgot what it is that we were building and why we were building it, because we were too focused on how to implement something.
The first time I encountered this dichtomy was when we were designing an application which would run some "tests" and produce data which would then be shown in various graphs and reports in the system as a reference value. There was a major flaw in this system right through the technical design and implementation.
We were calling it a "test" all the time, and never realized that when we have a test, that can either pass or fail. What we were doing is that, even if it failed, we were using the results of the test as the reference value. What we should have been doing was to realize that behind the thousands of variables, domain experts, and technical terminology, if the test failed - that indicated a problem, and we could not use the value as a "reference" anymore. And the reports and graphs would have no meaning without the same.
This is a good example of how a complete software development process with very intelligent people with lots of experience can completely fail, and the reasons for the failure really have nothing to do with the "technical design" other than that, there was NO conceptual design done here.
Much of this must have been difficult to follow and confusing as the issue seems obvious?. But we often sit quietly and listen to nonsense when everyone else is doing so, or someone very senior is going in a specific direction. Simple things get convoluted, everything seems directionless. All of these are as important as technical stuff.
In the next post, we will discuss the differences between configuration and status, why every engineer should know it, and why it is the most important thing which I never knew earlier. It is an excellent example of something which came down to a person as "tribal knowledge", "from experience", but can be considered as a very significant concept in Software Conceptual Design.
The Powered by Qumana
Going good dude.
ReplyDelete--Jaideep Panchal