Deepity is a new term for me. I've grown rather fond of trying to identify them in my daily life. Unfortunately, I believe I'm the number one source of them.
A collision of discussions about business opportunities and this term, made me start to look for them in software development, or rather the business component of software.
Starry-eyed programmers may dream of creating a Facebook or Google, and may have, in an attempt to align themselves with these giants, developed some nebulous idea for what their billion dollar company will do: "Connect", "Engage", or "Expand".
Fortunately, software really brings this to deepity practice to a halt. Software and its many development practices, asks the question right up front - "What is this going to do?" Or some variant like "What's the deliverable?" "Lay down the starting feature set?" Even without wasting your time building up user narratives or ideal user scenarios, your confronted with the limitations of deepity.
Thus here comes my didactic - If you can't lay out exactly what your billion dollar software will do in these simple terms, you can't program it and you don't really have an idea. You have something that sounds right - "People need to connect" - but doesn't really provide much value.
So yeah...work on that, and make sure to throw that in the face of the every hundreth person with a start up idea.
I love rails. I love that I can sit do and just sweep through the model layer, building out all that abstraction for an applicaiton within a couple hours at most. Likewise with the view layer, using the prebuilt urls (new,create,show,edit...). Reusing partials throughout, so I can take a static site and use some of the partials to build a dynamic one. It's fucking beautiful.
That said, when I first got into Scrum and was looking out building stories within the rails framework, it occurred to me that a lot of what made rails fast for development didn't exactly work for how I was writing stories. So I had two choices - change how I developed in rails, or changed how I wrote stories.
Well, it was obviously not going to be the first, so I changed the second. The main change wasn't so much the stories themselves, but the expectations that followed teh stories.
For example: "User can save a new contact." Off the cuff, this sounds like it would require a build from the model to the view layer, especially if the contact form was actually a lightbox or some pop-out, which would require some JS/CSS magic. Rails exposes that this may be a too big of story, or maybe that I need more backlog items in order to actually cover it.
Here's what I built instead:
- A new contact can be saved. - A user can save a contact through a webform. - Webform is integrated into the dashboard and a user can save there dynamically.
How the last two make sense as added features and they fit with my eulogy to rails above. First I build a form using the standard new template, then I render that as a partial once I get to dashboard integration. In this situation, I can do tests against the form, and leave all the work of the final feature to template/visual work rather than submission/controller work.
Finally, the first feature, segregates the model work to its own feature. A great way to confirm this functionality is to lean on the Unit test system that comes with rails. Now I could theoretically put all of my model tasks into one sprint and have verification of my feature, with the additional benefit of always having the ability to easily do regression testing.
Clients may not find this as sexy, but I think most folks get that setting up saving is the first step in building an application and the UI comes next, even if all you have to show (if required) is the console confirming save and data retrieval.
If you watch Independence Day, you'll notice a side character who appears in most of the scenes in the ladder half of the film - Major Mitchell.
It's Adam Baldwin (Jane from Firefly) and apparently this guy does everything in the military - he's initially the Air Force liason to the President, then he's helping corale pilots, and then at the end he's driving the jeep to go pick up Ian Malcolm and Will Smith. Simple question - the hell is this guy's job? If he's the President's liason, why is he later driving the jeep? Doesn't he have other work to do? Maybe he could delegate driving to a subordinate officer.
This is a general thing in movies - characters in organized, military or military-like organizations do a bunch of random tasks that they would likely just pass off to someone else.
Take The Avengers. Why is Nick Fury the guy who is running SHIELD day to day, and then he's also the guy that needs to check up on the Tesseract. Wouldn't he give that to a specialist in that field of research? Later Black Widow (a special agent who job is to beat the hell out of people) is flying a plane on a routine trip back to SHIELD HQ. Wouldn't you want someone more specialized in flying to do that? I get that Black Widow is a bad ass and all, but I assume flying takes practice to maintain skill. So I wouldn't necessarily want her to be the pilot. I'd want a pilot, which I assume since SHIELD's HQ is flying a fucking air craft carrier, that they have a couple sitting around.
See organizations have specialists for a reason, and leaders and important people need to do what they're good at and not waste time doing tasks beneath them. It's probably pretty insulting if you're boss is always coming over and taking the controls away from you. The upcoming jeep driver is thinking "Oh boy, here's my chance to drive the President. Moving up!" then Major Mitchell comes over and takes it away. Meanwhile, a hundred plus people are all waiting around for Major Mitchell to get back from driving so they can follow orders.
Heard a man on the radio claiming that all modern satire including The Onion and South Park are the legacy of the National Lampoon magazine. While I certainly owe a lot of laughter from my youth the folks who came out of that, I'm reminded that anytime anyone starts overreaching in their sense of influence they're full of shit.
I don't know about you, but typically when I hear the label "evangelist", I think of a branch of Christianity I have walked away from and dudes who got their heads chopped off for spreading the same religion.
So I don't really get the role of the Evangelist in the tech world. No - I get it from a business perspective. I just don't understand why the hell folks have decided to name themselves like this. At all.
(On a sidenote, why does the ad say "Coming to America" when he's helping the Toronto Maple Leafs?)
Consider the phrase Webguru or Webmaster. Gone the way of the buffalo, and you might just consider anyone who would bill themselves as such to be, you know, TOOLS!
So when I hear Evangelist, I think of an individual with a short lived job title that'll probably be looked at with disdain as some corporate branded hubris.
I have never handled alcohol well. I've rightly earned a reputation as an overdrinker. Typically, this is a joke among everyone who hasn't had to deal with my bullshit, most especially my wife.
But in software, drinking IS a joke. I've never particularly understood this. I find that software requires a fair amount of my wits to do well. Though, I will say software is aided by a bit of numbness, I tend to see this in the form of low light at night listening to RainyMood.
I've had three major careers in my life: cook, writer and coder. All of these fields have the reputation for heavy drinking. In reality, the only place where I saw it, and where I learned the majority of my bad habits was in cooking. You drink there, because there is fuck all to do after a late night shift, you're hot, you're in pain, you want to blow off steam, because you're poor, you got your ass reamed and it really doesn't matter if you're hungover, because your job actually feels better a little numb.
As a writer, I pretty much completely sabotaged my career by drinking. I worked mainly in copy, but the opportunities I was given by various editors to step up were typically ruined by drinking and quickly doing stories that were badly worded and poorly thought out. I was poor there too, but less so. But hey, writers drink right?
In my late teens, I learned HTML/JS (no CSS back then), C++/C, and PERL all on a POS laptop from my girlfriend's dad. Being a writer sounded sexier, so I gave coding to the cubicle drones. In my late twenties, I was back in the saddle. I found here too that drinking was just as encouraged and supported as cultural as my past two careers. This time, though, I had money.
If you can't tell where I'm going here, allow me to clarify - I think all of this is FUCKING STUPID. To cut around, the anecdotes and get to didactics - there is absolutely ZERO benefit to ascribing drinking as a part of coder culture. Coding is about building, intelligence, innovation, and cleverness. And alcohol benefits none of those things. It's antithetical to the culture entirely.
Software is the culture of late nights of coffee and Coke. Sometimes Mountain Dew. Sacrifice, for the glory of outsmarting the other guys, of creating Cathedrals. It has higher aspirations than the acctrument of success that goes with glorifying alcohol. And that is the only reason that I see this so common in popular depictions of coding. People who code are supposed to be rich now. And rich people drink to excess. Like they don't give a shit. They can afford to be out of it. In reality, coders can't and shouldn't.
Go ahead and drink. Seriously. I'm not being anti-alcohol. But don't ascribe it any power to code. For every crazy Friday with cheers all around, back it with hundreds of cups of coffee and bloodshot eyes.