Links
·
RSS Feed
Popular Pages
 |
 |
I haven't had the chance to read and review any books from the Pragmatic Programmers series. I decided to change that with the book Ship It! - A Practical Guide to Successful Software Projects by ...
-Thomas "Duffbert" Duff |
 |
They have gathered together the ‘best bits’ of various styles and methodologies they have been directly involved with, and combined them into a practical approach with the focus on delivering a pro...
-Mitch Wheat |
|
I was amazed that these five chapters only take about 160 pages and yet tell you all you need to know about successful projects. I’ve experienced a lot of these problems myself, and so did/do you, ...
-Javaddicts.net |
|
|
|
|
(Jul 13)
Quite often (and again very recently) I've run into a simple, but frustrating, misunderstanding. I'll often come to work with a team, evaluate their current state, and chart a path for them to move forward. For many of the teams I encounter, this ends up starting with continuous integration and test automation (along with a few other practices).
And I'm repeatedly finding that some developers, but nearly all managers, assume that I'm focusing on QA, or worse, that I'm in a QA role.
It's not that being equated with QA is bad. It's a compliment if you've known some of the testers I've worked alongside. The problem is with the fundamental misunderstanding about the role of automated testing. Automated testing isn't something you hand off to someone else; it's a function of your job if you're a senior software developer (or ever hope to be).
A sure sign of an immature or prima donna developer is the thought that writing automated tests are beneath them, and that someone else should write those test for them. Having someone else write your tests for you is what I call being a software pooper scooper. You're agreeing to follow someone else around and clean up their mess.
What's that you say? There is no mess? Really? If you think that you, or your team, can write tests with no bugs, then you're deluded. You're simply fooling yourself, but not the people who use your code.
Writing software is difficult. There are so many moving parts and we have to line them all up perfectly. Clicking through by hand isn't cost effective, or especially repeatable. If you want to KNOW that your code runs as you intended for it to run, then wrap it with an automated test. There's a small learning curve, but not much of one. Once you've written a handful, you'll find they take very little time at all to create. In fact, compared to sitting at a keyboard and debugging for an hour or two, you'll find writing an automated test takes no time at all.
And that's when you'll be on the road to being a real senior software developer.
Here are a few links for those of you just getting started:
My Junit tutorial
TDD for Embedded C
An Introduction to GTest
An NUnit Tutorial
Category: Agile
(May 23)
Here in North Carolina, we've got the best government money can buy!
North Carolina governor refuses to block anti-muni broadband law
I usually try to post more than a link, but this is just so disgusting that I'm posting the link and moving on.
Category: Misc
(May 4)
My article on Trench Warfare is in this month's Pragmatic Programmer's free magazine. Check it out and see if you're already working in a "trench shop".
Prag Pub Issue #23
Category: Misc
(Apr 14)
The great state of North Carolina is considering a bill that appears to be driven by Time-Warner and prohibit "predatory" local municipalities (you know, small towns) from rolling out their own ISP systems.
I'm no lawmaker, but I was born and bred in this great state, and have wished for a "predatory" town to roll out local internet service at a faster speed or better price and forcing my ISP to scramble to keep up. (My cell phone has faster upload speeds than my home internet service.) I've dreamed of having a "predatory" local town blanketing their downtown area with free wireless internet access in a bid to attract the technically savvy into the area.
Instead I'm living in a state where a state lawmaker that, from my point of view, would appear to be in the pocket of lobbyist, has sponsored a bill that would prohibit such a utopia. I suppose rolling out broadband to help local citizenry to compete in the new world of high tech jobs is too much too ask.
Rather than ranting on, let me provide a few links for you to follow on your own.
North Carolina cities mobilize against anti-muni broadband bill This link has the links you need to get in touch with the lawmakers running the committee currently considering the bill.
Cable-backed anti-muni broadband bill advances in North Carolina This is the article that first grabbed my attention.
Your NC Senator by county This bill has passed in the house. Let your Senator know that you care about this bill and that you'll be voting against and campaigning against anyone who votes for it.
Senate Bill 87 This is a direct link to the bill in question.
Please share this. If you have a blog, feel free to plagiarize this in it's entirety. I have no financial stake in this matter, but as a lifelong North Carolina citizen, I want the best possible infrastructure we can have at our disposal.
Internet access is crucial to the current, and next, generation of jobs and eduction. Let's share this message!
Category: Misc
(Mar 8)
The really hard part of changing an organization is changing the people, and that's not something I can tell you how to do in a blog post. However, I can tell you about five great practices that will boost your team's productivity, increase quality, and improve communications.
First, use continuous integration. It's a very simple tool with an enormous impact. A CI tool compiles source code after every check in, then runs every available automated test. This means that a developer who checks in code knows as soon as possible whether they've missed a file (oops!), or whether they've broken a test in another area. This type of rapid feedback means that your developers fix their own bugs, and learn from them, instead of having some poor dupe fix all the problems once a week. (See Jenkins for a good CI server.)
Second, require Defect Driven Testing (DDT). How often do you find bugs? Fairly often if your shop is typical. How often do you write automated tests? Infrequently, if your shop is typical. :) Instead you put in a large number of prints, or you step through the debugger for hours. And next week, when you find anther bug in the same area, you'll do it again. Instead, write a JUnit or Nunit test. It's simple, it's easy, and when the bug comes back, your CI system will flag it in seconds, saving you hours of debugging.
Thirdly, stop allowing groups to ask for features using Word docs. English (or any other written language) is very bad way to say something precisely. That's why lawyers make so much money trying to make it precise, then other lawyers always seem to manage to find loopholes. Instead, write simple tests. The automated tests we mentioned before aren't always unit tests. (In fact, they usually aren't!) If you ask for a new API, write a test showing how it'll be used. Need a new feature on the database API? Add a test. When the test passes, it's done. This is called executable documentation and it's an incredible communication tool. Use it between teams that are co-located, but especially when they're not. (Cucumber is a great tool for readable executable docs.)
Fourthly, use time-boxed iterations. Work for a month, or a week, and then stop. When you time box your work, it forces you to break down your work into more manageable amounts. We developers tend to be optimists and quite often (okay, ~always~) take on more work than we can complete on time. A time box lets us say "Done" or "Not done" in a very short amount of time. We get trained on breaking down our work, and our managers (or customers) gets to re-evaluate the work every so often and say "I wanted that feature when it was going to cost two iterations, but now that it's costing me 12, I don't want it this bad! Drop it out."
Finally, get developers talking with your customers. The perspective this interaction brings changes the way your team writes features, and it changes the way your customer sees your development shop. Both sides stop seeing stereotypes and start seeing real people.
There's a lot more you can do to change a shop, but these five tips will start you moving in the right direction.
Category: Agile
|
|
|
|
|
