Many technologists question their ability to write…yet the power of words is even more dramatic in technology than anywhere. As in mathematics, where a few symbols or formulas can create a paradigm shift and elegantly describe what would take hours and hours of discussion to communicate, the right words in technology can change the way we work and think. At the risk of losing all credibility with developers by displaying my naivete–I want to illustrate the power for good from a few choice words.

Agile

Apparently, in large corporate organizations, there are big bureaucratic processes by which software is developed and non-technical people are employed to populate and lead meetings. People actually use Gantt charts to project manage and there are infrequent (e.g. weekly) progress meetings that plot the interminable progress of long-range (6 month or longer!) software development projects.

In most of the small companies I have worked for, everyone had a list of things to do–a never ending list of priorty one issues, but really, they knew there was one thing they HAD to get done today in order to go home. In a fun company, the tech team would actually go grab lunch together and talk about what was bothering them. People worked together sometimes to get things done or they dove in to a frenzy of work to push through.

Wouldn’t it be great if you could add a little discipline to the informal approach? Perhaps you could have a daily meeting where people quickly shared not just “what they were working on,” but what they needed to get to that critical objective for the day.

Ideas alone resulted in frustration. Everyone had their own conception of what software development should look like and for most people in the trenches, it was expressed in the frustrating refrain of “tell me what to build” and complaints about “scope creep.” More effective leaders worked out ways to shorten development cycles but so much energy was wasted fighting against an assumption paradigm…until it was labeled waterfall development. Then, solutions could be named, such as the Agile Methodology.

My point here is not to write a tutorial on Agile Methodology or the many variants. But digging into these topics, I had the “oh, that’s all it is” reaction…not to minimize it, but to realize the power of selecting a few right words that stand in place for a change of thinking. Once adopted the methodology systematically attacks the dysfunctional paradigms that held back organizations that were inherently agile, but contained by a lack of common vocabulary and discipline of method. Incremental improvements never stuck…it took the vision of a new methodology that could be named and practiced, to break out of the dysfunction of the past. But, of course, there is new dysfunction, I’m sure!

Database Sharding

This is a topic I had to research recently…and in the abstract, it was a mysterious jargon word that created assumptions of complexity.

Apparently, for some companies, there is only one database; it is full of tables that serve many different functions. When things get slow, the company buys a bigger server or adds more memory.

In the small companies I worked for, we had the opposite problem. A developer would create a new database for any significantly new functionality we envisioned. The idea was that if we needed to someday, we could move the databases onto another server and balance the load.

Now that is a gross over-simplification, but it is the principle behind database sharding–separating databases and tables onto distributed servers. Next logical question: once you have that structure, how do you do cross-database joins and not kill performance? Perhaps you could create de-normalized view tables that are generated on a schedule? Maybe put those on their own server(s) too. Is there such a thing as a concept of a meta-data abstraction layer–a sort of database application server that would manage the abstracted data objects? How to handle that 200 million member database? Define the database connection string as a function using a pointer database or some other kind meta-data broker…

The beautry of language is that a single word can capture a concept that is intuitive to many already. THAT’s what I can call this crazy hacked up database we created! OK, well, after you apply a bit of intentionality to it, but yes. Now that we can name it and apply some standards to it, we can work with it and instead of thinking about it as a hack, it’s an architecture.

Once you “get” the concept, you are off to the races, talking solutions instead of problems. In other posts, I’ve talked about the value of punching through to a prototype solution using tools like virtualization, but language is an even more powerful tool in the quest for solutions…