Fuller Game Production

After leaving Raven earlier this year I took stock of my position in the industry. With 13 years of development experience and more than a dozen AAA products to my credit I knew I could add value to any number of organizations. But I wanted more than to be tied to one project at one studio for years at a time.

My greatest fulfillment as a developer has come from helping teams succeed. Maybe that sounds trite, but it's absolutely the truth -- I genuinely enjoy helping others. After much deliberation I came to the conclusion that the best way I could help the most developers was to go into independent consulting as a producer-for-hire, improving processes and filling in the production gaps for studios of any size, in any location.

I don't just want my current project to be well-managed. I want everyone to create a fun game that comes out on time, without overtime.
And with that end in mind, I present to you: Fuller Game Production

 Creating a video game is hard. I can make it easier.

When You Get A Chance, Recognize Excellent Service

I had a surprisingly good piece of customer service from a gate agent at SFO a few weeks ago. My flight was canceled and this agent worked with a few other folks to reroute dozens of severely irritated passengers. This gentleman in particular hustled his butt off and remained calm, professional, and courteous to the very last passenger.

So I told the agent's manager and sent an email to delta.com support. Apparently, it resulted in some sort of recognition for the chap. I couldn't be happier. People in service industries frequently get pooped on and, I suspect, rarely receive appreciation.

Here's the message for you, gentle reader...
Try to notice when someone does an excellent job on your behalf...and show some recognition. Chances are, they don't get nearly enough.

And CS... keep 'em flying.



---------- Forwarded message ----------

From: S*****, C*****
Date: Thu, Dec 2, 2010 at 1:20 PM
Subject: It's Appreciated! Delta Airlines observation November 6th, 2010
To: "keithfuller01@gmail.com" keithfuller01@gmail.com

Good afternoon Mr.. Fuller. I wanted to take a moment to personally thank you for personally giving the great feedback on the day I met you to my supervisor Gary and you went above and beyond and sent a personal email. I want you to know that it did not go unnoticed and I indeed got rewarded for it.

Whenever I receive positive feedback it's best appreciated when it's unsolicited ;-). It makes me feel that a "guest" really took the time to personalize it.

I hope that your holiday season is going great and I wanted to THANK YOU for acknowledging me. Enjoy the rest of your week!


C***** S*****
Delta Airlines
San Francisco
Gate/Ticket Agent

3 Things to Know About Smaller User Stories

Yesterday I attended a webinar by Mark Levison (graciously hosted by Donna Reed) about slicing user stories -- why to make them smaller, how to make them smaller, how small to make them, etc. Here are some of the points I took away.

Why Make Stories Smaller?

It's easier to estimate the work involved and easier to grasp the details. Further, when (possibly if, but probably when) you get partway through and start to realize how far off your original estimate was, you haven't spent as much time working on something that your product owner will pull the plug on after discovering how long it will take.

How Do You Make Them Smaller?

Mark had an entire page of possibilities so I won't get into enumerating them, but one of the driving thoughts here in breaking down the story size is that -- once decomposed -- you want to still be tackling a story that adds value to the project. You can find any number of ways to reduce story size, but make sure the resulting stories each add value.

How Small Do You Make Them?

The guideline Mark gives a team just starting off with Agile is to make sure stories are big enough that they take a couple of people a couple of days. If it's smaller than that it's really a task, not a story. (As an aside, he also pointed out that there's nothing carved in stone anywhere that says you have to use tasks when running an Agile project -- maybe that's something to bring up with your team.) So keep the story/task distinction in mind and don't break down anything too much.

My Thoughts

My assessment of Mark's webinar is that he gave a great, in-depth discussion on story size. It was accessible to beginners, but he answered some write-in questions that were more advanced in nature. Mark clearly has real-world experience in this realm and does a good job of clarifying the material. The idea of decomposing stories into reasonable size is applicable for game development, to be sure, so although Mr. Levison's talk was geared toward "standard" project development I'd still recommend this content for developers in the games industry.

My thoughts on daily standup meetings

Clint posted a great blog entry recently on daily standups in Scrum. I thought I'd add some of my own thoughts on the topic.

 

To anyone who hasn't been doing these, the term “daily standup” probably sounds like one of those dang Agile Terms. Or worse yet, a Scrum Term. To be fair, it is. But it doesn't have to be. There's no reason for any such connotations of methodology.

 

Don't get me wrong. I'm an unabashed advocate of Agile practices. But in many companies there's still a sense of newfangledness associated with Scrum. For those in such an organization, I'm here to tell you that daily standup meetings are incredibly valuable and can certainly be methodologically agnostic.

 

I've introduced standups to teams using the following points:

• I want to know what's holding you up each day so I can address it quickly
• I don't want to waste your time so the meetings will be short – discussions can be held separately
• We'll meet as a team so everyone can keep tabs on the project as a whole

Notice there's no mention of Scrum, Agile, or any other label. I've found that laying out the purpose and format of the daily meetings in this way assuages many fears and misgivings such as You-Don't-Have-To-Check-Up-On-Me-Every-Day-You-Nazi, Meetings-Are-A-Waste-Of-Time, etc.

 

After we first get together I might introduce the idea of answering The Three Questions. To be sure, it's ideal if you're with a highly empowered team that only requires the facilitation of a Scrum master here. But in non-Scrum settings it's not the end of the world if you still have to lead the group by asking the questions yourself. In my opinion it's more important to get the information out there and hear each team member contribute to the data flow than to get hung up on enforcing the ideals of Scrum.

 

A bonus for you, the manager, is that you get a chance every day to work on your soft skills. There will likely be a spectrum of personalities present in your daily standup and not everyone will be outgoing and easy to work with. You'll probably have this guy in your group:

 

You: “Emil, what are you going to do today?”

Emil: “Bugs.”

 

This is your chance to improve your own communication abilities. Make sure you're picking up on who's more talkative and who isn't. See what you can do to form bonds and occasionally cajole a lengthier response out of ol' Emil. If you learn more about him and address some of his recent accomplishments (“Thanks for implementing the classic controller layout so quickly.”) you might eventually get a two-word reply.

The bottom line is that daily Scrum standups are a great thing when they are driven by an empowered team – the people are focused on the task at hand, they care about the group's progress, and you barely have to do anything as Scrum master to get the necessary communication flowing. But even if you aren't in an Agile setting, you can still easily implement daily meetings that encourage teamwork, improve communication, and provide you, the manager, with the transparency you need to track the team's progress.

New Wolf Diary entry -- Tuesday, November 28th

I hadn't really thought this through when I started resurrecting these diary entries, but now that the entry dates are almost aligned with the current date I'm starting to get a little confused. I can only imagine how befuddling that must be for you, the returning blog visitor. Or even you, the intrepid first time reader*.

So to be clear, the title of this post ("blah blah blah November 28th") refers to November 28th, 2006 -- the date on which I originally wrote the diary page in question.

It's funny to think of how the landscape of the industry has changed in just four years. Notice some of the names in the latest diary entry. Quake Wars was still in production. Z-Axis wasn't Activision Foster City or Underground or...um, nonexistent. id was a major player. Or possibly even a playah. Hard to say. I've never been the most appropriate person to make that distinction. Point being, things change. A lot. In subjectively little time. And with that, I've managed to make a seemingly profound observation that's really just a paraphrase of 2000-year-old Socratic thought. Way to go, me.

*according to this blog's Stats page, this is actually a rather small demographic. Size of 1, in fact. Here's looking at you, xxx.xx.xx.255 of Ottumwa, Iowa.

Last night's IGDA-Wisconsin chapter meeting!

I had a great time chatting with folks before and after the meeting, especially Jeff Spurgat, a programmer with whom I worked at Evermore Entertainment about 12 years ago! (We both did a, "Wow, has it been that long?" :)

The Raven chaps were predictably excellent hosts and it was good to see such a large turn out. We filled the main conference room then brought in 20 extra chairs and still had people out in the lobby.

While I enjoyed hearing Rob Martyn's assessment of the state of the games industry, I found John Bergman's talk to be most intriguing. He spoke on Guild Software's ongoing Android development for Vendetta Online, which is Guild's MMO title. Some of the points I took away from his presentation:

• While the hardware is similar to iOS platforms, there are more bundling opportunities with Android
• Tough to design UI for touch-based devices
• Likes Tegra as a development target, mainly due to NVIDIA's history of working with game developers
• Sees the mobile development war heating up in mid-2011

It turns out Guild Software is based in Milwaukee, apparently not too far from the hovel I rented while attending UWM. Keep an eye on Mr. Bergman and his crew. Thanks for the great presentation, John!

More of my IGDA LF notes on Gamasutra

I posted my thoughts on a synopsis of Marc Merrill's IGDA LF session. Check them out at Gamasutra.

Notes from IGDA, part 1 (John Vechey, Popcap Games)

As promised/threatened, here's the first installment of my notes from the various talks, seminars, roundtables of this year's IGDA Leadership Forum. It's lengthy, but there was a lot of really good material to comment on.

IGDA LF, November 4th, 2010

Notes from opening speech, John Vechey (founder, Popcap Games)

I'll admit to coming into this talk with minimal interest. I knew very little of Popcap aside from the most basic of common knowledge: they make high quality, polished games and they pretty much created the Casual Games space. My own ignorance makes that sound like a fairly dismissive summation, which is unfortunate, because that's kind of like downplaying the significance of the mathematician who told Descartes, “You know what? I know it'd be tough to draw, but you should have a third dimension.” Who was that guy? Oh, nobody really. He just invented the Z axis, that's all.

Like I said, I started off fairly meh but the more I heard John talk the more interested I became. I'm going to just throw out some of the statements Mr. Vechey made and give my two cents about each one. Maybe you already know all of these points, but it was all news to me.


A 20-person company turned down a $60 million offer to sell

This actually happened early on at Popcap. The impression I came away with here is that everyone at Popcap wanted to keep making fun and they didn't feel that would happen if they sold the company. Maybe it was a matter of timing, maybe it was the prospective buyer...I don't know. But here's how I read it: these cats were presented with the choice of instantly becoming millionaires or staying true to their vision for their company. And they chose door #2. Respect.


Popcap is now up to 375 people and has been around for a decade

OK, so how'd that “no, thank you, we don't want your sixty million dollars” thing turn out for them? Pretty darned well, apparently. I'm not enough of a Pollyanna to believe that they created a superior future for themselves by being idealistic – although the ability to remain true to your vision is, I think, an indicator of values that fertilize the soil of success. Rather, I think they also had some pretty great leadership, excellent execution, and a boatload of persistence.

Every game would be better if it included a social graph (a la Facebook)

This is a pretty sweeping statement, but John's example of Minecraft is tough to refute. Let's just say I'm not sold on the absolute nature of this comment, but Mr. Vechey knows a heckuva lot more than I do about it. So if I had to recommend paying heed to his opinion versus mine...

Stay connected with the customer

Really, I think there could be an entire lecture – or series of lectures – on this topic. There's a ton of information to discuss here and I'm only bringing you a poorly drawn snapshot of the tip of the iceberg. Games that maintain a connection with the customer on any and every imaginable level have a great probability of making the customer happy and enhancing the game developer's revenue. A very simple example would be providing a web game X that rewards an achievement after 30 minutes of gameplay. And that achievement gives you $5 of in-game credit towards items you can purchase in game Y. What has that done for the consumer? What has it done for the developer?


Item-buy is a better business model than $60 purchase + $20 (or even $5) DLC

This makes me cringe a little, since my background is almost entirely one of AAA development – an arena in which providing attractive DLC is considered almost critical to getting a project greenlit. Almost nobody in the AAA space stops making a game after they ship it.


“I don't poo-poo technology but I haven't seen a technology problem that hasn't been solved by smart engineers.”

I put quotes around that because I made a point of exactly recording John's words when I heard that statement. It's a bit nitpicky, and I hate to look like I'm stooping to the level of soundbite-reporting so prevalent in this day and age, but I took issue with this because Mr. Vechey made it appear as though any idea with perceived value should still be pursued if it only represents a technical hurdle. Coming from a project management background as I do this smacks of – as Spock put it – two-dimensional thinking. Now, obviously the Popcap leadership is no bunch of dummies. And I'm sure they have a history of employing some pretty great technical problem solvers. But as a general rule if you get hung up on pursuing something because it's only a matter of time until your programmers find a way to overcome the current obstacle you might be taking a beating on opportunity cost, damage to your production pipeline, or even your long-term milestone schedule. Bottom line: If you aren't getting it done quickly (or at least on time) then it's not just a tech issue, it becomes a production issue.


“If it's a great game, we should make it”

My favorite quote from the whole thing. Because Popcap's games have traditionally smaller development cycles it was troubling a particular dev that he was working on something that could take three years to come to market. The dev asked if his work was relevant and this quote was Mr. Vechey's response. John went on to say that they should still make a game even if it will have a limited audience with a limited revenue potential – if it's great. It's one thing for someone to say that if they're an indie with a day job or an idealistic hardcore gamer looking at the industry from the outside. But when that comes from the founder and VP of Corporate Strategy for a successful company? Wow. Just...wow.

Back from IGDA Leadership Forum in San Francisco

This was my first IGDA event and I had a fantastic time. Even on registration night the day before the opening seminar I started meeting really interesting and passionate people (shout out to mis amigos at Kaxan Games!). It's great to be able to chat with folks who have been fighting the same fight as you have but who nonetheless have different perspectives and experiences.

And let's talk about the opening seminar! The inimitable Ike Harris of Zynga and the exuberant Kim Sellentin of SEGA Australia did a great job of setting the tone with their joint talk on Scrum implementation at their respective studios. And as if that wasn't enough they let me tag along when they popped off to In n Out for late night burgers.

The social aspects of the event were, in fact, even more meaningful to me than the purely informative nature of the sessions. Breakfast with the incredibly friendly Clint Keith, chatting about project management consulting with the unmistakable Michael Saladino, and discussing the horrors of suburban snow removal with Adrian and Kevin from Vicarious Visions all had a lasting impact for me.

I should really post my thoughts individually on each of the seminars I attended, so I'll save a few of the details for later. Suffice it to say that for folks in management and leadership positions in the industry, the IGDA LF is a highly recommended event.

Wolf Diary -- November 27th

I hope all the PMG folks at Activision know I have deep and abiding respect for them and that I've enjoyed working with them for the past 12 years. Otherwise they might take some of the comments in the latest Wolf Diary entry the wrong way. Adam, Matthew, Kekoa, Brian...you know I love you, right?

Guys?

New Wolf Diary -- November 22nd

Sorry I'm posting this a few days late. My girls had an extra long weekend due to teacher conferences so we've been running around having fun. The new Madison Children's Museum is fantastic, by the way. I highly recommend the human-sized mousewheel.

Regarding the Wolf diary, I had forgotten about the efforts we went through to get a writer working on the story and dialogue with us. To be honest, I'm not even sure who eventually received writing credit on the game. When I was on the project, at least, it was Marianne Krawczyk. She had a very agreeable demeanor and seemed willing to work in the shifting sands of Wolfenstein's foundation. She didn't even complain when I picked her up from her hotel in a Honda Civic with no muffler. What a trooper. Read on.

A Note to Commercial Airline Flight Crews

If a passenger were to watch you quickly and distractedly amble around your aircraft (thankfully, not one I was boarding) as you perform the most disinterested preflight check in the history of powered flight, it might just have a negative impact on his view of you, your carrier, and possibly the industry as a whole. Admittedly, I may be off base in my observations. Maybe the officer in question was doing a great job of inspecting his aircraft. I barely know the difference between a pitot tube and a lavatory (and let's be clear, failure to distinguish between the two could result in a painful and embarassing scenario) so take my comments with a grain of salt.

Also, the flight crew of United 5872 from O'hare yesterday performed one of the best landings in heavy winds of all time. Thank you, gentlemen.

New Wolf Diary -- November 21

In which The Schedule comes under attack by the nefarious forces of CantWeHaveMoreDesignTime.
Unanesthetized dental surgery is also mentioned, but in no significant detail. Read on!

Yay, my new book arrived

I'm now reading Implementing Lean Software Development. The Poppendiecks are huge names in the Lean/Agile world so I thought I should check out some of their material. I'm already fascinated with their brief history of the Industrial Revolution. I'll let you know how it goes.

Wolf Diary 11/20/06

Latest Wolf Diary is here. It's funny to look back and see that four years ago I was already becoming known for saying "no". 

Heh.

What? Another diary?

Yeah, I know...another diary? We may have uncovered why I was transitioned out of programming and into production -- I spent all of my time writing documents anyway instead of programming.

This was purportedly the 15th of who knows how many entries I wrote while developing SOF. Boy, I hope I find some of the others. Enjoy.

My First Layoff

Well, technically my second, but last time I had to walk someone out the door, not the other way around.

Something I didn't realize about layoffs -- and I don't know if this is just an Activision thing or if it's a federal stipulation -- is that the day you're let go you don't stop being an employee. Today is actually the beginning of our 60 days notice that our employment is being terminated. What that means to you, the consumer, is that I and all of my soon-to-be-ex-coworkers are still Activision employees and thus bound by the company's code of conduct. And, to be honest, while there are always going to be some really unfortunate effects from events such as this, I have to say that the whole affair is being handled with a lot more grace on Raven/Activision's part than many people have encountered at other companies. I've learned a lot about such things just in the past 24 hours and it's been somewhat eye-opening.

One of the things that I've always found unfortunate about layoffs and restructurings and realigning a workforce to better reflect a studio's upcoming slate is that you never seem to hear anything from the people who are let go. Which is a shame because layoffs tend to brand some very capable people with a frequently undeserved scarlet letter without giving them a chance to be heard. I hope that doesn't happen here.

Special message to my fellow laid-off Ravenites:

I've worked closely with almost all of you and I have a pretty good feel for what most of you are capable of. I know what you've accomplished on your various projects. I've also seen a few resumes come in over the years and I may be able to lend some insight into what prospective game industry employers would like to see when you start interviewing.

If I can be of any assistance to you, even if it's just to encourage you, contact me through comments on this post or through LinkedIn.

Most of you know that in my role as producer all I've really wanted to do -- what has given me the greatest satisfaction -- is to help you by removing the obstacles between you and success. If I can still do that for you in any way, let me know.

New Wolf Diary Entry!

November 17th is up. Wow, I had forgotten about the Deal or No Deal game. It actually turned out a lot better than I had feared.

Reminder to all Ravenites...keep watching this blog. Propriety demands that I not divulge what you're waiting for, but the wait is almost over. And I'm hoping I can help some of you if you need it.

Double Post!

Two announcements today.

1) In celebration of being with Raven for 4,290 days I thought I'd post an extra entry in my Wolfenstein diary this week. Behold -- November 16th!

2) Details forthcoming, but...Ravenites, watch this blog following impending events.

Steve Raffel retired today

Steve's the quiet, more reserved half of the pair of brothers that started Raven Software. They were indies before indies were cool. Bought an Amiga, hired some college students, maxed out their credit cards, and started a company that's still in game development 20 years later (and kept me employed for 11 years). I can't imagine what kind of drive and self-confidence you need to take a step like that. Well, whatever it takes, Steve's got it.

So here's to you, Steve. You've left a heckuva legacy. Enjoy your new horizons. Enjoy your family.

Enjoy your retirement.

New Wolf Diary Entry -- Nov 15th

This one's pretty lengthy, but such is the price of peering into the depths of history. Click here to read it.

Which do you prefer, column A or column B?

Which do you find more valuable in each of the following four lines, the set on the left or the set on the right?

•Individuals and interactions  OR process and tools

•Working game OR comprehensive design documentation

•Publisher collaboration OR milestone negotiation

•Responding to change OR following a plan
 
(Now feel free to read the whole thing on Clinton Keith's blog.)
I just saw his post on my Google reader and very nearly lol'd because...well... Suffice it to say that I know of someone in a production role who is actively engaged in abject defiance of at least 3 of those 4 value preferences. It will be very intriguing to witness the outcome of his efforts.

New Page Added -- Wolfenstein Diary

I finally dredged up a diary I was writing way back when I was working on Wolfenstein, an earlier Raven project. Check out the tab above. Or click here, I suppose.

How other studios do what they do

When it ships I'm sure I'll be able to talk more openly about it, but I'm working closely with another studio right now as they work feverishly to close their current project. I wish it were easier to catch a glimpse into the inner workings of other game companies -- there's so much to learn about the efficiencies (and, of course, perceived shortcomings) of people who don't work where you do. Who don't have the same entrenched bad habits as your company. Who aren't stuck in the same ruts you are. It makes me appreciate the value of someone like Clinton Keith who has been exposed to the inner workings of so many different studios. Being able to analyze the best practices of so many groups of developers, being able to determine what tools are best for which situations...I'm jealous of the guy in different ways than I've been jealous of him previously. I wish I could have had the experience of the past few months (and more experiences like it) several years ago. Imagine the improvements I could've brought to my own team.

Don't get a penny stuck in a garbage disposal

They are really, really hard to get out.

What do you consider the "cost" of the certification process?

For the sake of providing a concrete example let's consider 360 submission. I first think of the cost of certification as the time between shipping the game and being "done" with the game. The time I don't get to spend finishing the game. The polish time I don't get to have. The time I need to set aside for getting the team ready to...wait.

I suspect many people don't realize that from the developer's perspective, the game has to be done long before you send it off to manufacturing. It has to be done several weeks before that, in fact, so that (in this example) Microsoft can verify it's bug-free, compliant with technical requirements, etc.

This period of time requires you to have a significant number of people available for the inevitable top-priority bugs that MS comes back with. They may be rare crash bugs that you can't reproduce on your own (but of course the QA guys at MS can repro it enough to fail your submission). They may be multiplayer bugs that you never see on your internal network. They may be ninja controller pulls or crazy PC system specs problems or UI localization or... point being, the bugs that come back during submission or rarely simple to fix but are obviously the highest imaginable priority. I mean, if you don't fix these the game won't ship. So you've got to have folks on hand to fix this stuff during the submission process, even though everyone's pretty much sitting back with a "we did it, it's over" feeling.

When those bugs come back from your 1st submission, you have to have people on hand that can fix them, correctly and quickly. Those people aren't taking time off to recharge before the next project, they aren't doing pre-production, they're just...not doing work. And you have to budget for two submissions, so that's twice as much not doing work. Now, since you budget for two submissions you can assume you're going to fail your first sub (which is a very reasonably plan...MS can be pretty demanding) and therefore you keep fixing bugs and polishing the game. Then, when the Fail comes back from MS you take care of the bugs they found and your second submission is actually a better version of the game.

This actually bit us in the keister on Xmen2, though, where we had at least one bad bug that wouldn't prevent the game from being certified but we did want to fix before the game went to consumers. So we sent Sony the first submission thinking "we'll be able to take the next few days to fix this issue, then the first submission will fail and we'll include this fix in our second submission." Unbelievably, our first submission passed. We couldn't believe it. We wound up petitioning Sony to allow a second submission that included the fix for Bug X. Let me tell you one way to get Sony's hackles up...actually pass their submission process and then ask to resubmit anyway. Well, you, the consumer, did get a better version of the game out of it, at least.

So, yeah. That's the cost of certification to me. A number of talented people sitting around not making the game better. Maybe a good question for the future would be, "Is the cost of certification worth what you get out of it?"

What production methods should you use developing your game?

I'll work to come up with a more broad question next time. Dunno if I can top this one, though. :}

Allow me to preface these thoughts with the fact that my background is almost exclusively in AAA development. The smallest team I've worked with was about 25 people on the first Soldier of Fortune.

I know Agile methods are now such a hot topic that they've almost become mainstream, but I can't say even something like Scrum is required for successful development. I will say that my own limited experience implementing Agile methods has met with success, but it's still case-by-case as to whether that would solve more problems than it would fix. When I look at something like what Haunted Temple Studio is doing with Skulls of the Shogun I find it unlikely even a framework as almost universally applicable as Scrum would be more help than hindrance. I mean, they're four guys. And they're talking just a few months of development.
Is the importance of using a named method directly proportional to the size of the team, then? Well, going full on Wild West, code-what-you-feel with 200 developers seems unarguably questionable to me so maybe your team should be using something at that point, even if it's *gasp* waterfall. If you're working on the eleventeenth sequel to a particular sport game, though, maybe you can just do whatever you want. I haven't worked on more than a few sequels in my time, nor have I worked with a 200-person team so I can't comment authoritatively on that one.
That raises a point, though...does the familiarity of the project really determine how you do what you do? Or to put it in a more intriguing light, does the unfamiliarity drive your choice of methodology? If your team has primarily done shooters and now you're on a top-down action RPG, should that point you toward a more structured approach to your project? When we did exactly that at Raven we probably should've picked some sort of production methodology, I can tell you that. Instead, we drifted around a fair amount and took quite a while to create X-men Legends.

It may well come down to a case-by-case basis. The best general advice I could give is to ask the question of your project lead and/or studio management, "If someone brand new to the team came into your office and asked How does your team make a game, how would you answer them?" If you don't have an answer, or if it takes several tries over the span of several minutes, try to get someone in charge to sit down with you and do some research. Doing something new doesn't mean experimental or risky, but you should be implementing something with a wee bit more formality.

My First Question For You

What would it take for you to start a blog?