Everything you look for and all that you perceive has a way of proving whatever you believe.

Every now and then I am reminded of cognitive bias as presented by Kruger-Dunning in the paper Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments. As I have been active in the opensource community for close to 18 years now in some form or fashion the first lesson I learned is that if you have never done it before. You don't know. It's just that simple, and this lesson tends to stick with you with in almost every facet of life. It affects ones approach to problems such that every problem starts with one question. Quickly and summarily followed by a series of questions that need to be answered. My standard trajectory usually begins to branch off in a series of questions leaving me with few answers and even more questions to which I simply don't have the answer. Early on this led to a slight madness as I would start down some rabbit hole and end up working on some esoteric issue that affected a handful of people. In retrospect, I was young and dumb, back then I thought that so long as you plugged away at it. No matter how long it took you, you would be able to answer anything. Now that I'm slightly older, and know how dumb I still am and how valuable it is in choosing the right question, I am able to avoid madness. Of course, sometimes it will sneak up on me and I find myself doing something that makes absolutely no sense at all. This is obviously why we call it madness, but I'm much better at avoiding it or tolerating it depending on my needs or condition. I'm of the mindset that madness can't be cured, only managed.

Usually if I receive an email or a critique of work furnished that needs a sign-off, peer review or some such. I'm wholly open to it because my first assumption is that if I'm treading new or unfamiliar water then I obviously don't know what I am doing. Secondly, the more eyes the better. While treading familiar waters I am much less open to critique or suggestion unless I feel it will beneficial, primarily to avoid rabbit holes but also due to a lack of time. New variables mean risk and if there is no gain by adding the element of risk to something that has been tried and true. I'm unlikely to entertain or even respond to it. This is not necessarily always the case but largely this behavior I feel has strengthened my ability to stay focused on the right question and to avoid rabbit holes.

I think proponents and participants in opensource operate within the same vein and mindset for the most part. It's more of a behavioral mindset or lifestyle, propelled by the some itch, urge, quest to solve a given problem and find the right answer. Whether it be for fortune, fame, enjoyment or some other facet. You work the problem until you are tired and move on to some other problem whether it be in the same domain or somewhere else. Hopefully you were able to answer a question or two and because it's opensource inevitably someone at some point will continue finding answers to questions old or new.

I'd appreciate much more answers however

Lately though with my own interactions I feel as if this isn't the case, partly because I suspect their is a racial and gender tinge to cognitive bias that is ripe for exploration. This brought up in a couple of discussions on gender recently. Specifically in regards to women in opensource and generalizations of women by men in general. Before these discussions a couple of weeks earlier I had recently finished reading a post by Daniel Stenberg titled "Three out of one hundred" (which I recommend you read) so the conversation and ideas were fresh in my head. Also, I had a heated discussion about some work where I can only make the assumption that because of my skin color this person thought that somehow they knew better and would simply do the exact opposite of what I said. To be brutally honest, sometimes this works in my own favor, and to be blunt, I'm a capitalist and love money so cleaning up a mess may work out for me in monetary fashion. I mean, ignorance is costly, but let me be clear. Unlike agile salesmen, I try my best to offer clear and abrupt warning.

On the whole though the idea is that men on average will make the incorrect assumption that they are more capable at a technical subject than their female counterparts no matter how qualified they may be. Women having to deal with this their entire lives tend to see the bigger picture and avoid what they consider to be rabbit holes. As a woman I would ask why? Why even bother going down that route if every time I do someone is going to offer to second guess me? This coalesced quite nicely with another discussion I had on generalizing untrue statements as applied to women. So, let us take for example the statement, "all women are batshit insane" as clearly being a gross generalization. Amongst a group of men shooting the shit  it may be viewed as an off-cuff remark, in a mix of women, it will still be viewed as an off-cuff remark but it will be normally tolerated, at least to your face. However, this one statement in and of itself subtly reaffirms subconsciously that there must be some bit of truth to that statement. Thus, most women are indeed insane, maybe not batshit insane but a mild course of irrational behavior is expected. Of course this statement is simply ridiculous! I don't have the actual data to back any of this up and saying I believe it to be true isn't enough for an idiot, I realize. That aside, I am ashamed to admit that I am guilty of remarks like this myself. I've tried to rationalize the comments with "it's about context" but I can't qualify that as an "african-american" male. Is the statement "black people know jack shit about computers" any different? It's generalistic, and is again ridiculous but do we subconsciously hold onto these ridiculous generalist statements and again subconsciously use them to validate our own cognitive bias? Of course if that is actually the case there will be less women in opensource because all the men seem to think they are superior. Can you really blame someone that can't get a word in edgewise, everything they do is second guessed, or felt to be inferior? Doesn't sound fun to me at all, especially when you are paid less and have to doubly prove yourself answering harder questions. In short, fuck that noise. So of course, there will be less of any group that isn't already in the majority. Which means we have much less answers to our questions. This is unacceptable and we must try harder not just in our professional but personal lives as well.

The Mary Protocol

In response to my own behavior and to help me realize when I may be making a generalist statement that I may not consider hurtful, insulting or a turn-off to someone. I've implemented the Mary protocol. It's a simple procedure that will help me, help myself.

1. The moment I may have said something and/or heard someone else say something that sounds ridiculous enough to either retract with an immediate apology or to pause the conversation with a "not cool". I will do so.
2. I will not argue about my position beyond stating that i'm invoking something known as the Mary protocol to help myself from reinforcing my subconscious with nonsense and to allow for open discussion if the offending party would like to hear more.
3. I will do my best to keep any proceeding conversation succinct and within reason.

The protocol is to be like a bit of a tase to correct my behavior. Not because I want to become some righteous feminist with a penis but because should I have a daughter someday I'm quite sure i'd take high offense to anyone calling her batshit insane, or treating her in inferior manner in anyway shape or form. So much so that I pray to never see it occur in my presence for the safety of the offending party. Off-cuff or not, it's not acceptable behavior and I will not continue it. It is my hope, that you do the same.

Share/Bookmark

1. Should you need someone to tell you to chop up your project into smaller units that are more easily digested? You're a bad manager/team lead/leader/whatever you are calling yourself. Needless to say a two or three year old is smarter than you and that MBA money went to waste.
2. If something is a smaller unit, that doesn't make the problem you are trying to solve through programming or anything else any easier.
3. If you need someone to tell you that you need to sit down and discuss what you plan to do before you do it? You're a bad manager/team lead/leader/whatever you are calling yourself.
4. If there are more bad than good things to say about something. It is rotten, throw it out.
5. No external force can run your company better than you and your employees.
6. Team building involves no methodology, it's a constant reassessing and making tough decisions. You want to make your weak programmers strong and reward your stronger programmers appropriately. If you need someone to tell you this. You're a bad manager/team lead/leader/whatever you are calling yourself.
7. If you are a programmer that can't say "I don't know, i've never done it before" or "This will take too long for X reasons" and/or "I don't know anything about X". Grow some backbone, you seriously aren't all knowing either so stop acting like a dick.
8. If you are a manager practicing Agile in any context. You're a bad manager/team lead/leader/whatever you are calling yourself.
9. There's nothing Agile about agile; Work is work, someone has to do it no matter how you cut it up. Agile doesn't make your resources work faster, more smoothly or any of that.  Building a comprehensive team does that; not some methodology.
10. Why can't you all be like Google and have the best programmers/admins working for you? You don't reward or pay a decent salary, and then on top of that you use crappy ass tools. Google is only successful because good programmers decide to work for Google; not because they have some secret sauce. That's how it works for ANYTHING. When the best people want to work for you well then you're gonna corner any market they are in. If all of Google's programmers left tomorrow they'll be a closed shop soon as those programmers go to Doogle.com or whatever.
11. How can I get the best programmers working for me? Choose the best tools and only the best tools. They will come looking for you; guaranteed. In your next job posting put "We like to use these tools, because they are the fucking best most awesome kickass tools available and we are building great shit." Also, i'd recommend not having HR write up the copy and less the profanities. Keep it simple, short and to the point. See what type of reaction you get.
12. Software engineering is mentally draining. It's not like filing papers. It isn't rote, so you can't treat your employees like it's some factory line.
13. The best feedback you get is from your programmer and if he/she gives you a comprehensive reason on why X is horse shit and it makes sense. Heed that warning.
14. Here's a typical stakeholder request. "I want to go to Mars". Here's a typical agile response "Lets break that story down into tasks and see how best we can do this if possible or break the overall problem into multiple sprints". Here's a typical Christopher Warner SW response "Well, I don't know if i'm in the right room at present but this is not fucking NASA, there would have to be a lot of work to get there. Maybe you should think about getting to Florida first".
15. Here's a typical Agile question "If you're in space and lost your tether and you had X tools which one would be best to use in aide of saving your life". Here's a typical agile response "The gun would be best". Here's a typical Christopher Warner response "You're fucked". It doesn't matter what tools you have at that point. The idea is to NEVER lose your tether so you never have to make that decision.
16. How do I know I have a good programmer/admin? He or she is usually busy getting shit done, and pretty much needs little to no management. They tell you what's going on, how things are progressing. What issues problems, concerns they may have etc. Pretty much everything is quiet on the front when they are around.
17. How do I get a team of good programmers? Good programmers will want to work with good programmers. Primarily because when one gets lost it pays to have a decent wing man or someone who can say "Welllllllsssssstttt this isn't working because you're a fucking idiot and wrote this module wrong, you're a dumbass. We'll work it out over lunch.. you know what?? lets finish this in X's office she's working on some similar shit; we'll order up. Bang this out and then hit the gym, after the beer you buy me. It always taste different when you buy it".
18. How do I reward my team? Contrary to popular belief, money is on the top of the list but sans that proper recognition. Beers and pizzas and all that shit, save it for highschool. At the very least offer expensive liquor, we are all adults here.
19. How can I be a better manager/team lead/leader/whatever you are calling yourself? Make sure the road is paved and fill in potholes. When something from the top comes down that is horse shit? Say "This is horse shit". Don't go back to your team with a "This is horse shit but we have no choice."  Say "This is horse shit, I said it's horse shit and I explained the detrimental waste of fucking time. They still want to do it. Of course, you guys are free to do something more awesome and when asked I'll show them more awesome with a, my apologies, I guess this more awesome thing I have right here will have to suffice" or "Sorry we just can't fucking do this stakeholders.. It's just not possible for X reasons, the top one being that I know my job better than you and this request is simply in management lingo, UNpossible". Wrap that in termination free language; unless you happen to be in a mood in which case have another job already lined up and be sure some of your team can come. Don't want to abandon them.
20. "I don't know anything about computers I just want a measurement of when I can expect things!" When it's done, or accept variable estimates. Unless for some reason you believe the art of writing a program to be a measurable unit of work. In which case, let me explain. Writing a program is much like being an artist. You start with a blank canvas with a couple of constructs and then you have to take whatever came out of the human MIND and create a reality out of it. Think it's easy? Think of anything you have never built before until now.. Now go build it, but before you do. Tell me when it's gonna be done. I'll wait.
21. Anything successful takes a long time of proper foundation building, team building and regression. If you don't have that or experience it. You will not be successful. It's that simple there is no methodology or luck involved besides hard work and building a good team. FOR ANYTHING.

Ok that's enough. I hope you apply "Software Engineering" as a method to your next project; even if it isn't software.

LAMP. Linux/Apache/Mysql/PHP,Perl,Python is THE opensource software solution stack for programmers/administrators doing almost anything, specifically rapid application development on the web. There are numerous frameworks that pull all the pieces together in hopes that large and parcel anyone can build robust and usable web applications and websites. This includes content management. For the most part this works well, even through the hurdles of getting all of the specific components to work together nicely. Unfortunately the masses have taken the context of building anything to mean that LAMP is the ONLY solution to building applications on the web.  So the standard de facto has been to look at a problem and automatically assume LAMP as the underlying technology for the space. Blog? LAMP. Twitter like site? LAMP. Website for my company? LAMP.  Simple web page with a small contact page? LAMP.  To be fair, this works well for many context spaces. Especially because the LAMP system is highly modular one can literally pull one piece of the overall solution set and replace it with something completely different. However as any engineer and architect will tell you. When building a bridge, it helps to know what is going to travel over it, under it, through it and unfortunately, into it. If not you end up with something like this.

The collapse of the Ironworkers Memorial while under construction on June 17 1958. Collapsed during construction due to miscalculation of weight bearing capacity of a temporary arm.

This is generally what content management tends to resemble when it meets the architecture of LAMP. The software solution set is a complete failure for content management applied as a standard de facto solution primarily because of the M in LAMP. In this case I mean Mysql but the problem in actuality is any RDBMS or Relational Database Management System. It's not the only problem but it's one of the most critical components to getting the idea of content management right.

Lets start by taking apart the LAMP acronym.

Linux; As far as the operating system goes. Linux is a tried and true system which has been under development for nearly two decades. It has consistently pushed the envelope in regards to utilizing the underlying hardware to provide a robust and capable operating system that can scale from the server to the desktop.

Apache; As far as web serving goes. Apache is again, tried and true and has been under development for nearly just as long with many lessons learned. It is the standard de-facto server for serving static/dynamic content with an extensible and modular system which makes it capable of providing support for many different applications and setups.

Mysql; The relational database management system that had the honor from many as being the first RDBMS they used and the cut throat bare bones data solution. In early Mysql releases there was no idea of ACID Atomicity, Consistency, Isolation, Durability in the project. This overhead was seen as generally a problem that could be solved higher in the application space but for the most part everyone using Mysql during that time had no need for such compliancy. This made Mysql extremely fast and of course, with the exception of Postgres (which did concentrate on these things) it was opensource and freely available. Things have changed much since those days, Mysql has generally become ACID aware and is surprisingly owned by Oracle.

Perl/PHP/Python; For the most part Perl as a language was dominant in the 90's. Since then it's fallen behind in regards to the web application space. There are numerous reasons for this but one of the major reasons is that many new programmers have written Perl code that is difficult to read and maintain. The language wasn't originally intended for large object-oriented projects (Ruby which has syntax largely like Perl was written primarily with object orientation at its core and the Ruby language has a vibrant community and a popular web app framework called Ruby on Rails or ROR) and maintenance has generally become a nightmare. This isn't a blackmark against the language past it allowing poor practices that have seemingly been embedded with the programmer. As those new and junior programmers become more literate their Perl code improves but those old projects and web applications they've written or help write don't fare as well. There tends to be a group-think backlash against the language because of that. "It was written in Perl? Ugh.. nightmare".

PHP tends to have the same exact problem, low cost of entry, except the community around PHP is wholly vibrant and releases often. PHP as a language itself has had many of the same problems as Perl in regards to building a large software project. Most of which have been remedied with time, namespace support, halfway usable object orientation support etc. It still lacks many commercial features that you can't readily use without purchasing them or their frameworks.

Python on the other hand, has a much higher cost in regards to learning curve than the previous two. However it's still a very easy language to learn and enforces many good practices out-of-the-box that the other two languages don't. Proper formatting, a useful object oriented system, the idea of namespaces, unit tests and code structure. These are all important concepts in architecting software (building your bridge) and it's a viable language.

Ruby isn't a P but needs mention as it's also a dominant language used. It's highly object oriented and as stated above has syntax largely like Perl. It's essentially referred to some as "Perl done right"  and it's primary author has stated that "I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python. That's why I decided to design my own language".

So what is the problem with Relational Database systems and content management?

Relational Database systems are from an era where object-oriented programming didn't readily exist large and parcel. The concept of an object quite frankly was  foreign. Most programming had been functional and procedural, no one had any idea how useful it would become. The general crowd-think was more concerned with "records"; it had worked well since the 1940's and many companies had spent large sums of money setting up internal systems. A nice line printer spilling out data onto dead tree's with a list of users, phone numbers, etc. It was easy, pulling out all of this information. However as time passed and with the advent of the internet the concept of object-oritentation became more important. Java came to dominance because of this. We needed to do more than just relate information but also update it real time, expose it to other systems in-house and to our partner systems. Records in a flat table were simply not enough, we wanted to have a representation of a user and all of the attributes important to us updated dynamically as they were updated by our staff, customers or both.

Computer languages started to reflect this fact. Most languages started receiving object orientation methodologies. C got it's OO super set in C++ and then there was Objective-C which got it's clothing from Smalltalk and obviously Java. Which sparked a new commercial trend and is probably the most dominant object oriented program in use today.

Square vs Circle, Cube vs Cylinder, Oil vs Water.

Unfortunately, as the way we wrote programs changed, the way we stored the data our programs created or needed did not. Programmers began writing Object Relationship Mappers ORM's to map the objects they created in their programs with the way they stored their data. So one would design a user object with a name, address and phone number in their program and then have to create a table for this in the relational database and then have to map between the two. Obviously for time sensitive applications the overhead of conversion became an issue. More importantly though a whole system to manage the consistency between the two became an issue. If one got out of sync with the other it would cause no small amount of trouble for critical applications.

Enter Object Oriented databases or OODB's. A programmer could create the object in his program and store it into an object database. Early versions were considered slow and inefficient however OODB's tended to hold more data than relational database systems, were generally faster than relational databases as there is less to lookup and no overhead or extra systems to manage between a relational system and an object system. As well as being more secure it seemed like an easy win however there was no uptake. Most commercial organizations were and still are used to the idea of a "record" and Oracle as a company is simply a good salesman; they came up with Oracle Object Relational support. OR in more simple terms a superset to SQL to make Oracles relational database behave more object like. Also the sheer force of SQL and the relational database eco-system made it hard to see through the clouds. In-fact, most people didn't and don't even bother looking. There was no real advantageous reason to go with an object oriented system if you had an object relationship mapper. Summarily, no one took up OODB's except for organizations in the know, primarily scientific and engineering houses who had large amounts of data they needed to warehouse and work on. Every one else stuck with RDBMS, until it started hurting them. They would eventually retool by either finding and consulting with Oracle or one of the commercial Object Oriented Database providers. It's a testament to Oracle's success that they are the ONLY database game in town. Really, what other commercial database company can you refer to off the top of your head? I'll wait... Right, so that leads to the present day where there is more talk of Nosql databases (object databases, graph databases, high perform key/value stores etc things like HadOOP, CouchDB, MongoDB, Redis, Neo4j, Allegrograph) but not much has changed in the last two decades. This time around things seem much different and the database playing field is bound to go through transformation with web semantics and html5 database standards. We can only wait and see.

In the interim the previous decades were simply unfortunate for database stores and summarily the content management space as it is highly object oriented. Your customers want to manage content. Videos, Users, Large lists, Blogs, News, Images etc. All of which are objects that need to be stored somewhere, and for the most part that is occurring in a relational database. Which means one has to overcome the problems above and 9 times out of 10 it requires a lot of time and engineering that simply isn't done properly. Hence choosing the standard de facto in LAMP, the bridge eventually collapses. A collapse maybe downtime, or loss of records, or constant maintenance, security threats all of which can be lessened by building the correct bridge for the problem space. In content management that is an object database; or some combination of nosql/relational and object data depending on application.

How do I change the M in LAMP to an O for object database or something similar?

Well, if you plan on managing content there is ZODB or the Zope Object Database for Python which is part of the overall package for the Plone Content Management system. There are also DyBase, db4o, Twig etc. Past that your options are currently limited without an object relationship mapper but it pays to understand the problem space so you can architect your content management solution appropriately even should you need to keep your data in a RDBMS. Whether it be for something as simple as management of blog data or a large list of data it pays to know that you have a bridge that can withstand all of the nets elements. Hopefully, next time you are talking with your consultant, client, design company or web team and you hear LAMP you have a better idea of what it entails and how to apply your business needs and process using LAMP if you need to. LAMP isn't always the answer and it certainly isn't always the answer for content management solutions.

This is when a light bulb goes off even though it's ever so dim; you just need to make your own content-type. If you're lucky enough, you would of already did all the work like myself and will just need to continue on. The bright idea of you reusing Plone AT Content types for more than just a boolean option or some string material is just a dumb idea. Seriously, it's just a dumb idea.

You may still think it is a bright idea. I really mean it. It is not. Go ahead.. Try it. I'll wait........

See? Dumb idea. If you were smart and heeded this advice without trying it then you've just saved yourself a couple of hours worth of work. So when is it a good idea to use archetypes.schemaextender? Well if you need some minor annotation to an overall content type it makes sense. Usually information that you won't have to display readily or override views for. You know, like a boolean option that will trigger a subscriber or some such. Or some other tiny bit of stringfield information where it's just a tiny change and not much of the overall schema is being modified.  When you start talking about more than that, just go with your initial gut feeling and do your own thing. If you really want the functionality from the default Plone content type you can always rip it out and throw it into your own content-type.

Now today doesn't feel like such a waste. Cheers.

1. http://pypi.python.org/pypi/archetypes.schemaextender

Share/Bookmark

Yes, I know what you just said. The meaning for the terms in the element set are so obtuse that it can be interpreted almost in any fashion. Thinking about the possibilities becomes almost mind numbing. .oO "Simply the standard is broken by not being specific enough Mr. Christopher, blah blah, lets hit this beach". "Whatever dude, who cares.. no one. that's who. No one gives a shit, pardon me while I drink this beer..."  It need not be so however. Instead of recreating ones own metadata set which is doing the same exact thing. We should be looking towards exposing this data and then ADVERTISING that it's available. It's also easy to simply generate the required data for most of the 15 resources with ease.

How does this help? Well, at the very least people who respect each others Copyrights/Rights and would like to give attribution will know exactly who or what institution to give it to. As well as helping to nail down where data originates etc. It's not perfect by any means and the holy grail solution most likely exist in a W3C standard that gets accepted by the major browsers.

In the meantime maybe it's high time the DCMI community came up with some badges that simply state "This site or resource is DubliCore aware" or "These resources have DublinCore metadata attached" or just a graphic that highlights that we can indeed review or pull the metadata. There is a nice plugin for Firefox called Dublin Core Viewer that does this. Also exposing the data as naturally as possible ie: "Creator" == name of user or some such is also generally good behavior. "Goddd, you're still yapping about this?? Ronnie, pass me another beer.. i'm gonna leave if you keep talking this clickety-click bullshit".

ok.. I'm done... for now.

Share/Bookmark