Over the years I have found out that having something like this happen, many times over, is an essential step in acquiring a solid design background, because it gives you an ability to let any idea go the moment it is ready to be seen by others, at any stage, and have it be torn to shreds and re-assembled and considered and taken away by your Creative Director and given back and smoothed and roughed-up as the team navigates the space of unknowns in a process called Designing, without going to pieces or hampering the process by being defensive. You have to go through this process over and over and over to get over investing ego into a design, and you have to get over that ego-investing if you choose to have many minds work together to make it better.
Interestingly enough, I do not remember much of this during getting my degree in Software Engineering. Most of the results were graded by whether the program actually worked, there was some cursory look at the code, a discussion of API design, and that was it. There wasn't a grind of having every line, the structure of every call, every class, every interface dissected, discussed, called good, called bad, over and over and over. Scrutinization of the coding or architecture design process didn't happen to a significant degree.
The same happens afterward. One of the most educational activities I did in all my software engineering was being part of a group code review. One of us would present a problem we were trying to solve or some object or family of objects we needed to make to allow a task, and then we would all look at the code, line by line, all of us, compare it against the style guide we chose to follow, exchanged ideas about how to make single statements or whole blocks more efficient, what pattern of the Gang of Four it fit best and what the implications of that was for surrounding code.
This exercise contributed most to making me a better programmer. And in 11 years of being a full-time Software Engineer, I got to do it all of, oh 7 times or so. Because instead of this rigorous learning evaluation, our code is evaluated on whether it works, and if not, thrown back to us to debug. We only get a second pair of eyes when we are seriously stuck, or when our code gets maintained by someone else, at which point the stories appear on about how terrible the code is on some Code Disasters site. It is so seldom pro-active before.
Maybe in some institute of higher learning about Computer Science there is a class where the students carefully craft APIs for complex libraries, and the class, as a group, evaluates them not just for whether the implementations work, but what established patterns of design they follow, what their future strengths and weaknesses will be, and how they will scale based on similarities of well-known APIs or libraries already in production. Maybe there is a class where the top graphics or sound or application APIs are evaluated against each other, and the underlying coding is scrutinized for style, brevity, and maintainability. Maybe there is a whole set of classes that is not just about making UML diagrams, but what UML diagrams are actually for. If there is, I have not heard of them; it is always "here's the API, code a program, make it pass the test suite, the Teacher's Assistant will grade the code by looking at it for 5 minutes."
Which means Software people do not get the exercise of not getting ego-invested, of being able to let the design go. In between all the buggy systems, buggy operating systems, vendor systems that do not operate as promised, a fundamental lack of knowledge whether we actually can deliver on time, budget, and spec, while the world is expected of us, we get invested in how we make it work, we get a sense of pride every time we solve this puzzle. And many of the questions a software architecture has to answer can not be asked at the beginning, or seem ludicrous (like the Twitter people ever knew when they started out they would have to run half the world, tweeting, on their systems, while hundreds of rabid startups would try to create an ecosystem on top) so it is really hard to do objective evaluations. During crunch times, scope creeps, and fickle angry customers, you hardly ever get time to create a test prototype of an architecture. You just have to do.
The result is that software architecture meetings can get testy. And that when software creator transition into the more visual or product design world, they have to learn to let go of any personal involvement of what they make, and actually mean it when they say they seek deep criticism. It is quite the little mindswitch to do when not already learned in school. But very necessary. And in the end, very satisfying.
