Whoa…

~ Andrew Stellman ~ 1 Comment

Whoa!

Well, we didn’t see this coming. Check out what Tim O’Reilly says in his latest blog post:

I was probably most surprised when I saw Programming WCF Services on our list of top performing books for the year. If you’re steeped in open source, you might never have heard of Windows Communications Foundation, Microsoft’s approach to building SOA applications on Windows. And you might not care. But you’d be making a mistake. Don’t count Microsoft out of the Web services game yet! They still have a brilliant, passionate developer community, and as a company have tremendous resources, persistence, and talent. And now that they have real competition, I expect them to reinvent themselves. (For that matter, Head First C# was the top selling programming language title in Bookscan last week, except for “Javascript: The Definitive Guide”. And C# continues to gain significantly on Java in terms of book sales.)

Wait, what? Let me repeat that for you. Except for a book on Javascript, Head First C# was the top selling programming language title in Bookscan last week. That’s pretty amazing to me, because we only released it at the end of November, so word of mouth hasn’t even gotten a chance to spread yet.

We took a few risks with Head First C# — we took an approach that was somewhat different than any other programming book I’ve seen. I’ve learned at least a dozen and a half programming languages over the years, and I followed the same pattern every time: I thought of a project that I wanted to do, then I figured out how to do the project using the new language. (Like back in 1994 or so, when I wanted to learn Perl and also learn about web servers, so I built a web server in Perl.) But I’m definitely not unique in this approach: pretty much every good programmer I know takes the same approach to learning a new language or technology.

Which is why I thought it was so weird that I couldn’t even find a language learning book that asked you to solve programming problems. I’ve seen a lot of “hands-on” work, where you follow step-by-step instructions to type in code to get a certain result. And certainly, an enterprising person can definitely learn that way. (If they couldn’t, nobody would buy programming books!) And certainly, we have a lot of that in Head First C#. But I just don’t think that’s enough.

I guess I have a hidden agenda here. I’ve led a lot of programming teams over the years. In 2006 and 2007, I spent a lot of time working with a consulting company, and one thing you learn working with consulting teams is that you need to work with a lot of different people. Often, you’ll have at least one very junior member on a team. And what I’ve found is that a lot of really junior developers have the capacity to be good programmers, but don’t have any experience independently solving programming projects on our own. So I decided early on that one goal of Head First C# would be to give people that experience. I wanted to teach them how to solve programming problems, rather than just follow step-by-step instructions. In essence, I wanted to create programmers who I’d be happy to have on my team in the future. (Does that sound too self-serving? I hope not!)

So when Jenny and I started working on Head First C#, it took us a few chapters to figure out exactly how to do that. It was interesting going back to the beginning of the book after we finished, to do a second pass and incorporate comments from our (really great, and really patient) tech reviewers. It really did take us about five or six chapters to work out a good way of assigning problems. We ended up co-opting the “Exercise” element that you’ll find in the other Head First books. The Lose Weight Exercises in the other Head First books were generally pencil-and-paper oriented, although I think I remember a few step-by-step programming ones as well. That’s definitely the approach we took in Head First PMP, and it worked really well.

But with Head First C#, we took the “Exercise” element in a totally different direction. We basically used the Lose Weight Exercise to give a programming assignment, where we’d give a problem to solve. We’d include a screenshot, define some classes, maybe give a little of the code, and then leave it up to the reader to build working software. It was lucky that I spent so much of my career writing specifications, because I think we really had to push our writing skills to the limit. It’s far too easy to write an Lose Weight Exercise that’s ambiguous or hard to follow… and as we found out during the tech review, it’s really demoralizing to run across a poorly-written Lose Weight Exercise. And we had to be clear that there’s no single, “correct” solution to the exericse: if it works, then you got it right. I’d be surprised if a single reader comes up with exactly the same solution that we did on any of the projects in the last third of the book.

I hope that interactive approach is what’s paying off. Word of mouth is just starting to get out, and I’m really happy to say that it seems to be positive.

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

~ Andrew Stellman ~ Leave a comment

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

~ Andrew Stellman ~ 1 Comment

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.