Juixe Techknow

Software is not like traditional engineering disciplines. Unlike a bridge whose requirements are essentially set in stone, software requirements consistently change and evolve with the needs of the business. The requirements, of say civil engineering, are more firm and concrete than that of software engineering because the artifacts that are being constructed are usually large physical objects like a road or bridge. In the other hand, software is malleable and it often refactored easier than business constraints, that is why product managers often prefer to wedge a round peg (software) into a square hole (requirements) as business constraints evolve. But unlike a kid’s shape sorter or pegboard set, the peg and the hole are consistently changing and not always into the same shape.

Shape Sorter Toy

When working with legacy code, there is a big difference between a developer trying to add or fix a feature and getting it to work and another developer trying and giving up only to recommend a complete rewrite. From my experience, the one main reason why any person suggest a complete rewrite of an existing application or feature that works for a large install base is only because they don’t understand it. I would be suspicious of any engineer or developer if he or she recommends to rewrite any large portion of a existing appellation just because because they don’t understand it.

It comes as a no surprise to technologist that Google would pull the plug on Google Wave, I just didn’t expect it so soon. I also didn’t expect Google to kill it’s Google Nexus One phone. As a user of Google products, I am always apprehensive to use new Google products because they have a track record of just dropping support for products they deemed unsuccessful with little or no notice. Google has been known to buy products like Jaiku and Dodgeball only to kill them after a year. The other products that I have used and Google has killed include Google Notebook, Google Video, and Google Page Creator. This is one reason I would not use any Google product still in beta, which is most of Google’s products, for mission critical applications. Most of Google’s consumer applications are free, such as Google Docs, Google Mail, and Google Search but only because they provide zero customer support. In fact, you have a better change of finding a Google employee or Product Manager through Twitter than you do through their About Us, Contact Us or corporate website. It’s joke that you can’t even find Google customer support page for any of their products even if you use Google Search.

Google prides themselves in hiring really brilliant engineers, bordering savants and the top 5% of MENSA, and it designs products for users just like them. Basically they design for nerds, and the first response you will ever get when asking a question to a technology focused group is RTFM, and this is how Google treats it’s users. Google expects it’s user to comb through Google Groups, do Google Searches, and ask your colleagues via Google Voice because Google does not see as it’s job to help users with Google products, but to create new products and see what users use, and see how they use it, how much they use it, and how they can learn from users behaviors.

So one is left asking, what product will Google kill next? Orkut? Chrome OS? Google Reader? Google Knol?

In a typical day, software engineers, use diagrams, charts, and a ideograms to represent the software systems we work on. The biggest problems with software can also be described visually, such as the following image which tries to explain problems of software engineering.

Software Engineering Explained

When software engineering is that complicated, just imagine how the software application produced in such an environment looks like.

How Software Looks Like

Creating a clean, simply to use, functional application is harder than you think. Only a few companies have been successful with simplicity. Most enterprise applications look like a mosaic of buttons and text fields.

Stuff That Happens UI

Here is a screen shot showing the complexity of a software application.

FileMatrix UI Complexity

If you have any images, graphics, diagrams, or charts that illustrate the complexity of software engineering feel free to share in the comments.