Building Video Games – a great way to improve your C# skills!

Invaders

One of my favorite things about Head First C# is that Jenny and I ask our readers to do a whole lot of coding. When we started doing research for the book, one thing that really struck me about other books to help you learn C# was that I couldn’t find any book that actually asked its readers to write much code. There were one or two that we saw which had some written Lose Weight Exercises. And that’s great for a textbook, but I don’t know any programmer who learned to program with a pencil and paper. If you want to be a good programmer, you need to write a lot of code. Coding is a skill, and like any other skill it takes practice. And there are a lot of concepts that just don’t “click” until you write software that uses them.

I know that when I need to learn a new language, the first thing I do is come up with a project for myself. Like when I needed to learn Perl back in 1994 or so. I also wanted to learn about how web servers worked (they were newfangled and mysterious at the time), so I wrote a simple web server in Perl. (It turns out that it only takes about 50 lines of Perl to write a very simple HTTP/0.9 web server… probably a lot fewer, if you’re an insane Perl optimizng type.) So we decided from the beginning to make sure Head First C# has plenty of opportunities for our readers to write code. Which meant coming up with projects… a lot of projects.

Which turned out to be harder than it sounds. The instructions for the project needed to be completely self-explanatory. It’s not like an Agile project, where the programmer can talk to the customers and the software can go through several iterations. No, every project needed a complete specification, one that the reader could understand completely and build exactly the software we asked for.

And that’s where video games came in really handy.

When you ask someone to write, say, a business application, you need to explain all of the details of the business. And you need to explain why the program is needed, especially if the programmer doesn’t really have any background in that business. If a programmer doesn’t understand the reason or rationale for a particular feature, then it’s almost certain that he’ll build something other than what you’re asking for. (That’s why I always like including a rationale section when I write use cases. It prevents a lot of problems later in the project.)

Video games come “pre-loaded” with their own rationale. Nobody ever needs to ask why you’d write a video game — you do it because they’re fun. Everyone already knows why you’re writing it. It’s not hard to make a video game intuitive. One easy way to do it is to model it after a game that already exists. We have one Lose Weight Exercise where the reader builds a Go Fish! game, where the player plays against two computer opponents. One project is Hide and Seek — the player searches through a virtual house to find an opponent who hid in a random place. We’ve got a dungeon game, a Whack-a-Mole game, and my personal favorite (and the final project in the book), Space Invaders.

There are plenty of other sorts of projects, too. Our goal was to get the readers coding from the very beginning, and keep them writing code through the whole thing. We designed the projects to be satisfying and fun. And we’ve already gotten feedback from readers who definitely enjoyed them.

Head First C# Labs — The Contest

We’re running a little contest for our readers. We’ve included three labs in the book where the readers build larger projects. We give them a lot of design, but we don’t actually give them the code for the solutions (like we do for all of the smaller projects). Eventually, we want to post executables for the labs. But we don’t want to post our own — we want to post executables that our readers came up with! So we’re running a contest to see which readers can send in executables first. The first person to send us working code for the lab will have their executable posted on the website as the official solution, and we’ll send them some sweet O’Reilly swag, too.  Here’s the contest page — we’re looking forward to seeing what our readers come up with!

UPDATE: This contest is closed, but check out the Head First C# forum for a new challenge with prizes!

Some great questions about PMP and Agile development

What the…
Jenny and I are doing a really nifty Q&A on the JavaRanch Saloon. People are asking us all sorts of great questions about Head First PMP, and we’re doing our best to answer every single one of them. We’ve gotten a lot of really good questions about Agile and how it works with PMP. It looks like some people assume that there’s some basic conflict between running an Agile shop and how a PMP certified project manager might typically run a project. Some of the questions were really good, and I think some of our regular readers would be interested in the answers I came up with. So here are a few of the best questions and answers from the forum in the last couple of days.

 

HF PMP: how does it fit with Lean Software Development…

Gian Franco asked:

How does PMP fit with practices as explained in Lean Software Development (by Poppendieck) or Agile practices in general?

I wrote a blog post about this a while back called “What About Agile?”

https://www.stellman-greene.com/2007/04/27/what-about-agile/

There are definitely a lot of things that the PMBOK(r) Guide and PMP exam cover that aren’t addressed at all with Agile — like whether a fixed price contract is better or worse for the seller than a cost-plus contract. But there’s one really important way that both the PMBOK(r) and Agile are very similar: they both recognize that managing change is an important part of a successful project. And in that respect, you’ll definitely find that your knowledge of Agile can help you when you study for the PMP exam.

And Gian had a follow-up question:

Well :), let me put it in another way…, In Lean SW development requirements churn is considered to increase costs, I don’t know much about PMP, but suppose it resembles to Prince2 (another comparable projectmanagement method) then the initial phases of specification might fall in this category of specifying too much too early.

The PMBOK(r) Guide was developed so that it can be applied to any kind of project, not just a software project. So projects that fit into its framework tend to develop all of the requirements up front, before any work begins. That’s because all of the plans for the submarine or office building need to be finalized and agreed upon before you hire the construction crew to break ground.

There will be changes that happen. But if those changes involve very large alterations to the blueprints and you need to tear out the last three floors you put in, it gets very, very expensive.

Oddly, the same is true of software in many cases. There are some changes that need to be made, and which you could have found had you “churned” through the requirements a little more before you started building the software, and now you’ve got a bunch of code you need to tear out — and it would have been a lot more efficient to take the time up front to figure out the requirements and then only build your software once. Unfortunately, many people don’t consider that “Agile”. (I think they’re wrong — I think that doing a lot of iteration before you even start writing code can be the most efficient and customer-focused way that you can build software… but that’s a story for another day.)

 

HF PMP: PMP is Agile!

Darya Akbari asked:

Can one say that PMP is not agile :) ?

That’s an interesting question. But I’d ask the opposite question: can an Agile shop fit into the PMBOK(r) Guide framework?

The reason is that the PMBOK(r) Guide doesn’t define one specific set of doing things. In fact, just the opposite. It says that you need to select a particular methodology based on what you know about your industry and past projects, the specific needs of the project, the deadline and milestones, etc. It doesn’t say that every project needs to include specific things. Instead, it includes things that typically happen on most projects — and practices that are most commonly found. And remember, the PMBOK(r) Guide doesn’t just apply to software: it needs to be general enough so that it can include practices for construction, industrial, civil engineering, electrical and other kinds of projects.

So can a typical Agile process fit into the PMBOK(r) Guide? As far as I can tell, the answer is yes. One hint is that when Jenny and I were working on “Head First PMP”, the PMBOK(r) Guide team members on our technical review team repeatedly stressed iteration and iterative development.

One of the strongest points in the PMBOK(r) Guide (ones that is stressed on the PMP exam) is that it really emphasizes collaboration with the stakeholders, and keeping them in the loop on all important decisions. Another thing that it really stresses is responding to change — and it’s very clear that the customers need to be involved in decisions about change.

There are definitely some things that Agile people might not agree with. It may seem very documentation-heavy, and very concerned with contracts. But the PMBOK(r) Guide was developed in a world where subcontracting is very important, and where a lack of documentation or attention to the contract can mean that the company can get sued and go out of business. I’ve spent a lot of time working in a consulting situation, and even the friendliest clients can turn into adversaries if you don’t have everything documented properly. But if you go back to the Agile manifesto, you’ll see “Individuals and interactions over processes and tools,” “Customer collaboration over contract negotiation,” and “Working software over comprehensive documentation”. While the PMBOK(r) Guide highly stresses individuals and interactions, customer collaboration, and working software (in the form of deliverables that meet the customer’s needs). But it needs to pay attention to processes and tools (since that’s what a framework is made of), contract negotiation (because a process is no good if it puts your company out of business), and comprehensive documentation (because it’s really hard to build a strip mall or highway overpass without it).

 

HF PMP question: SCRUM?

Rogerio Kioshi asked:

I’ve read about SCRUM. Does PMP have anything to do with this metodology?

The PMP exam won’t have any questions specifically about SCRUM. But if you have a good understanding of SCRUM, then that will give you a good leg up on studying for the PMP exam. The reason for this is that if you’ve spent time thinking about SCRUM, then you probably have a good understanding of a lot of the ideas behind team communication, project schedule constraints, and activity sequencing, and those are core concepts that you need to understand to become PMP certified.

You’ll still have studying to do, though!

 

Need advice on HOW to start a new Software Product

This isn’t a question about Agile specifically, but it’s still a great question. Paul Michael Laborte asked:

I hope this doesn’t sound too off topic. Anyway here it goes…

I’m currently a software developer with a Monday to Friday job.
Right now, I’m looking for opportunities which would allow me to have a 20% time (pretty much like google).

During that 20%, I’m thinking of developing my own software product.
I would be needing to wear different hats so I really think HFPMP would be of great value.

Aside from the contents of the book, would you have any other tips for entrepreneur aspirants like us

That’s a really interesting question. How do you start out a software project?

Well, if you want to get your project started out right, the first thing you need to do is figure out what it is you want to build. That might sound a little odd — of course you know what to build, right? Otherwise, why would you start a project? But if you look at a lot of projects that went off the rails at one point, one thing that you’ll see over and over again is that many problems can be traced back to the fact that one person wanted to build A, while another person wanted to build B.

There are a lot of tools and practices that can help you with this. My favorite is a Vision & Scope document — mostly because it’s very lightweight, only takes a few minutes to write, and it’s something that anyone can read if they want to learn what it is your project does. Also, it’s something that serves really well as a front page for a wiki or project website, and immediately brings people up to speed on it. Basically, the Vision & Scope tells you very briefly who needs the software, what their needs are, and how you’ll meet those needs (by explaining the features of the software you’ll be developing).

To be perfectly honest, Head First PMP may not really help you as much with this particular problem. But it’s something that Jenny and I wrote a whole lot about in our first book, Applied Software Project Management. We have a whole chapter on starting out a project using a Vision & Scope document.

Other things you need to think about when you’re starting out your project — which we also talk about in depth in Applied Software Project Management — are figuring out how your users are going to interact with the software, setting up a version control system, and doing test-driven development.

I definitely recommend taking an hour or two and really think about how you’ll handle those things. One way I’ve seen a lot of people do this is start a wiki for your project, and have a separate page that says how each of those things will be handled. It doesn’t have to be fancy or anything, and it shouldn’t take long to throw together. But just doing that will really help get your head straight about them, and set your project in the right direction from the beginning.

 

If you’ve got a burning question and you’re wondering what we think about it, send it to us using our “Contact Us” page! We love answering questions from our readers.