The good folks at Microsoft’s Columbus office are putting on the second annual Dogfood conference. It’s a FREE two-day event loaded with content on Silverlight, WPF, SharePoint, SQL Server, Exchange, Azure, F#, Windows 7, and loads of other neat stuff.
The conference runs 12-13 November at Microsoft’s Columbus office.
Check out the conference’s agenda and register! (Note that you have to register for both days separately!)
If you’re not following CodeMash on Twitter, you may have missed the announcement that the session list for CodeMash 2010 is up.
The selection committee received 450 submissions this year and had an insanely hard time working through them. All 450 were terrific submissions. The committee came up with an awesome lineup!
Registration for CodeMash will open up shortly, and it will go quickly, so be ready to jump and get in line!
If you’ve got a great idea for a conference session, you absolutely have to spend time getting your abstract right before you submit it. Your abstracts really need to pitch to two separate audiences: the selection committee and the attendees themselves. Work hard to explain the value folks will get from your session.
Here are some thoughts based on my experience writing a few abstracts.
Your speaker bio is every bit as important as your abstract, particularly if you’re not well-known by the content selection committee. Writing a great bio is a topic for another post, likely by someone else because I’m contrarian and non-conformist with my bios. Just do me one favor: make sure your bio isn’t longer than your submission…
Here’s an example of one of my abstracts. Feel free to borrow, copy, or outright steal it and adapt it as you need.
Title: Leadership 101
Abstract: It doesn’t matter what point you’re at in your career, you need to understand some fundamentals about good leadership. If you’re well into your career you need to know how to get the most out of your teams. If you’re just starting then you need to learn what good leadership looks like – and how to help ensure you’re getting the leadership you and your colleagues need to succeed. In this session you’ll learn basic concepts about respect, responsibility, communication, and teamwork, based on experience drawn from Jim’s years of serving in the military, playing competitive sports, and working in a wide range of jobs.
Feedback:
“I knew Jim Holmes was a good speaker, but holy crap. That's a great way to start a day.” Joe O’Brien, http://is.gd/2ovna
“Jim Holmes is a fantastic speaker... Audience is completely engaged in his Leadership 101 talk at #erubycon” Raju Gandhi, http://is.gd/2ovxN
I’ve been a part of teams organizing a pretty good number of developer community events here in the Heartland over the last few years. I’ve helped with medium-sized Code Camps / Days of .NET hosting 150 - 200 people across four tracks and I’ve helped with much larger events like CodeMash, where 550 people attend seven tracks plus open spaces.
While those events are really rewarding, they take a significant amount of time and effort to put on. You generally need several people working as a tight team to pull these off. You need a big venue, you need audio visual support, you need food, and you need significant sponsor support to pay for all that. Many times you’re hostage to your venue’s catering services, which means you’ll be paying high costs for mediocre (at best!) food. (Thank God for the Kalahari, where the venue’s food is actually really good.)
Twice in the last year I’ve been part of great events which were a snap to put on: the .NET University last November and the Software Engineering 101 last week. Both these events filled the room (90+ people) and were a great success. Where CodeMash generally has well over $100,000 go through the cash register, metaphorically speaking, both .NET U and SWE101 were put on for less than $500 each.
Here are a few concepts you can use if you’re interested in putting on an event without the tremendous work of a larger event.
This list isn’t all that long, is it? It’s all common sense. You can do a great event on the cheap. You can have a whole lot of folks learn some great content and come away all excited and motivated to improve their environments. You can do this without giving yourself an ulcer and losing sleep. Honest.
Go do a neat event. Get people fired up.
Then do more.
Wow. 90 or so folks showed up yesterday for an amazing event: the Software Engineering 101 Conference. Everyone seemed pretty fired up, energetic, and happy at the end of the day after hearing Leon, Scott, and Jon cover some great topics.
We went through Object Oriented Programming basics, SOLID software design, code metrics, and production debugging. All these were fundamentals[1] for an afternoon of test driven development in a hands-on workshop environment. Leon, Scott, and Jon delivered some great content and really got the attendees engaged before proceeding into the afternoon workshop.
The afternoon workshop was really, REALLY fun to observe. There was a tremendous amount of energy going on in the room as folks paired to solve the problem given them: part of the rules engine for Greed from the Ruby Koans.
One interesting thing really struck me: how quickly all the attendees jumped in together and got productive in pairs. Pair programming freaks a lot of people out for a number of reasons, so it’s sometimes hard (at least in my corners of the .NET world) to sell. We never even gave the attendees a choice. We told them in several pre-conference mails that the afternoon would be pairing. Leon fired off the workshop with “Get ready to pair.” Not once did we open the door for folks to work by themselves, and I think it really paid off.
We’re looking at some possibilities for repeating this conference, perhaps even as an online/live session. More news on that if anything comes of it.
This was an awesome day for me, and I’m really thankful that Leon, Scott, and Jon jumped on board when I pinged them. I couldn’t have gotten three better presenters in the Heartland, and that’s sayin’ something because the Heartland kicks every other region’s assets for speakers.
One last thing: many thanks to EdgeCase and Cardinal Solutions for jumping in with sponsorship funds. We were able to get food, drinks, and snacks for the attendees, all courtesy of Joe and Jeff. Many thanks also to Microsoft and Brian Prince for opening up the venue to us.
[1] I had someone remark that Scott’s Production Debugging presentation wasn’t on the same content line as the OOP, SOLID, metrics, and TDD sessions. They were right. BUT! I pulled in Scott because A) his session has a tremendous amount of fundamental material in it, B) He’s an awesome presenter, and C) I wanted to see it and I got to pick the conference’s content. :)
In my Leadership 101 talk I really harp on the importance of leading from the front, particularly as you get higher up in an organization. I illustrate this with a story of the battle of the Somme in France in World War I. The allied generals were so far from the front they didn’t know about flooding which made it impossible to cross the battlefield in any effective manner. Tens of thousands of casualties resulted in the first day of what turned in to a long campaign. All because the generals lead from the rear, where the environment was completely different.
I just don’t understand “leaders” of an organization who don’t take the time to learn the details of the environment their organizations operate in. How can you lead if you don’t know your environment, your clients, your company, or your people?
The Dayton Daily news had a great article in its Sunday paper on executives and upper level management at Miami Valley Hospital here in Dayton who are terrifically engaged and at the front. Leaders there do four hours of “rounds” a week at the hospital – as doctors do rounds to visit their patients, executives and management do rounds to visit their workers. They also interact with their customers – the hospital’s patients.
This is a terrific practice that keeps the hospital’s leadership in touch with the pulse of their workers and the hospital’s patients. The article, plus its two companions here and here, highlight the great benefits the entire hospital is seeing because of these policies.
Making this sort of effort ensures leaders understand the environment their people are working in. Leading from the front ensures leaders understand the environment the company creates for its customers. Leading from the front ensures leaders are keeping open lines of communication to workers and customers, and are seeing things about their company first hand.
It doesn’t matter if you’re leading a huge company of 70,000, a small company of 150, or a team of three. You’re jeopardizing your success if you’re not consistently and frequently getting out to interact with clients and workers.
Lead from the front. The benefits are amazing.
I’ve got a couple speaking engagements coming up over the next two months:
Be sure to look me up if you’re at any of those events!
(And if you’re looking for speakers at one of your events, I’d be happy to send you my current list of abstracts, if’n you’re interested.)
Now listening to "Polaris" by Jimmy Eat World
Doh! I missed the mail that my 2idi wasn’t providing my contact service any more, so the “Contact Me” link on my sidebar hasn’t worked for, uh, more than a couple days.
It’s fixed now, and you can use 1id.com’s service to get in touch with me.
Sorry for the goof, and thanks to the reader who let me know about it!
Now listening to "All Too Well" by The Kingpins
Living Green, the Missing Manual by Nancy Conner, pub by O’Reilly, ISBN 0596801726.
This book can be preachy and a bit breathless in some of its content, but it’s really a fascinating and educational read.
Conner works hard to cover a lot of topics and gives you material on everything from the chemicals you may not know about in your home to alternate and renewable energy sources. Along the way she also covers raising a green family (I raised two kids via cloth diapers and was happy to see them covered), building/remodeling, eating green, responsible shopping, and a number of other topics.
A number of topics were thrown out without enough evidence of whether or not there’s really a basis for concern (the impact of volatile organic compounds offgassing from foam in furniture or dryboard markers, for example), but generally Connor does a very nice job of giving you a good background on the topics she’s writing about. There are also a lot of resources referenced in the book so you’re able to go look at more material from one side of the story, at least.
While there’s a chapter dedicated to “Reduce, Reuse, Recycle,” Brown seems to carry that theme through the book. I don’t know if that was intentional or not, but I found it very helpful to consistently find small reminders of those principles in many of the book’s topics. I’m a proponent of reducing the number of things around me and trying to reuse as much as possible – but I’m nowhere near as good at it as I’d like to be.
Overall I enjoyed the book and found it very useful.
Now listening to "Alive" by Off-Kilter
During devLink a few folks from the region’s community were gabbing about a variety of topics, including burnout, motivation, FUD, and a number of other topics.
Keith Elder pulled out his recording gear and ended up capturing some really interesting commentary from a lot of people. You can listen to the podcast on Keith and Woody’s Deep Fried Bytes site. (They’re also on iTunes, so go subscribe if you haven’t already!)
There’s some tongue in cheek references to this being a group therapy session for Leon, but the discussion’s really so much more than that. A number of the community’s most active members offer up gems of wisdom on a wide range of topics.
It was fun to participate in the discussion, and it was fun to listen to. (Much more so than the DNR show which gave me heartburn enough to write about elsewhere…)
Now listening to "Date of Rebirth" by Origa
Last Saturday I was lucky enough to participate on a devLink discussion panel on “Has Software Development Gotten Too Complex?” The panel was hosted by, and recorded for, Dot Net Rocks and posted early this AM as show #476. The panelists were Billy Hollis, Kathleen Dollard, Josh Holmes, and me.
We spent a bit of time talking over various topics, then opened up for audience questions. Some of the questions and comments were pretty interesting, particularly those around the vast increase in power we’ve seen through advancements in our technology. We’re far, FAR removed from the days of having to do minutia infrastructure work (as opposed to choosing to do that when we have no other choice).
There was also a very weird undercurrent that quite frankly brought me down. We heard complaints about FrontPage hitting its end of lifecycle, we heard laments about the confusing amount of choices for technologies, we heard complaints about Microsoft “forcing us to use three ‘servers’ for all our applications,” we heard complaints about the lack of plain Notepad-based examples.
The Twitterverse had lots to say on the topic, some supportive, some negative, some exhausted. “DNR” means lots of things, so that results page has lots of chaff. Regardless, read through it.
Here’s some tough love from Jim, folks. God/evolution/whatever built an amazing piece of equipment in your body: a brain. Moreover, that brain has a wonderful, but far too underutilized ability called Critical Thought. Use your brain and Critical Thought. Use them to solve problems. Use them to decide how to stand out above your competition. Use them to figure out how to crush your enemies, see them driven before you, and to hear the lamentation of their women.
Yes, many things in our industry can seem overwhelming at times, but you know what? You are utterly, absolutely capable of dealing with all this. Moreover, you’re likely capable of not just dealing with it, but succeeding – but only if you’re willing to invest in yourself for the long haul.
The harsh reality of our industry is that the vast majority of folks in it aren’t concerned with improving themselves, so just the fact that you’re reading this blog, or attending conferences like CodeMash or devLink means you’ve got a great start.
Take that start and run with it. Get involved with a local user group. Hit more conferences. Expand the list on your regular blogroll. Work hard at your place of employment to carve out time for regular training sessions – and I’m talking on a weekly basis. Lunch and learns are a powerful way for you to ensure you’re keeping in touch with the changes in the industry.
Oh, by the way, I’m not just talking the hard technology issues of what you build, I’m talking about you learning to improve how you build software. Learn about testing. Learn about the *DD du jour. Learn how to improve your processes.
Jesse Liberty wrote a nice blog response with some of his ideas. I enjoy Jesse’s writings and presentations immensely, but I have one huge issue with his suggestions: his ideas are all 100% Microsoft-centric. That’s OK, but we as problem solvers absolutely cannot limit ourselves to using only what Microsoft provides. For example, if you’re evaluating what data access strategy to use, then you’d darn well better not limit yourself to looking at LinqToSql or Entity Framework. You’d better include the much more mature alternatives like NHibernate, SubSonic, or rolling in some variant of the ActiveRecord concept. Furthermore, you’d better be asking hard questions about how any examples or “best practices” coming out of Microsoft fit in to your particular environment.
Use your brain, folks. Turn your discouragement into an opportunity to improve your ability to stand out from the others. Turn that into an opportunity to help your company or organization differentiate itself.
(I’ve written and re-written this post a number of times since coming home from devLink and the panel. I’m still not satisfied with it, but here it is. The lack of clarity in this post is a sign of how conflicted I am about the episode. Sorry, but it is what it is.)
Now listening to "Hare Krisna" by Thievery Corporation
Problem: You’re trying to RDP to a remote server and you get the message “The terminal server has exceeded the maximum number of allowed connections.” You need to be able to examine current open sessions and kill unused ones.
Solution: Open a command prompt from an account with admin privileges. Use the ‘query’ command to find out who has sessions open on the target system:
C:\Users\jholmes>query session /server:myserver
SESSIONNAME USERNAME ID STATE TYPE DEVICE
console 0 Conn wdcon
rdp-tcp 65536 Listen rdpwd
schambers 1 Disc rdpwd
schambers 2 Disc rdpwd
We can easily see that someone’s hogging up the sole two allowed connections by logging on, then killing the RDP session while still connected. Nervy.
No matter, I can fix that quite easily with the ‘reset’ command:
C:\Users\jholmes>reset session 1 /server:myserver
This kills the session Now I’m able to RDP on to the server without being blocked by someone who wasn’t cleaning up after themselves…
Last weekend I was at devLink in Nashville. On Thursday I was trying to finish up some work and looked for a quiet spot, so I headed to the then-empty room where Open Spaces would be held the following two days. The room was a chapel at the venue’s campus; a great quiet spot where I could try to focus and get some things done. The room had lots of windows letting in beautiful natural light, and there was a wonderful high, vaulted ceiling with some nice decorative architecture. In short, a great place to get some undisturbed work done.
Up at the front of the chapel was a table with two signs taped on it:
Interesting. I wondered about the rationale behind the signs, but I was in a hurry to get some work done, so I sat down in a different corner and tried to finish up my tasks. In between productive sprints of work, my brain kept coming back to the signs. “Why?” I wondered.
Eventually, I began to think about how others might react to the sign. Being ever-interested in how my community hommies react to various things, I even went so far as to mention the sign to a few folks the next day.
“Hey, the table in the Open Spaces room has a sign that says to not move the table,” I mentioned.
One friend said “The sign says not to move it? I’M MOVING THE DAMN TABLE!”
Another pal said “If I need that space I’m moving the table.”
A third simply said “OK, so we won’t move it.”
All three reactions were somewhat interesting, because none of the three asked “Why’s the sign there?” My first friend, being somewhat wonderfully contrarian in nature, was going to move the table simply because he’d been told not to. The second was going to move the table if he needed the space. The third just agreed to deal with the limitation and move on.
Bear with me, because there’s actually a point here.
Flash back to Thursday and my quiet working time in the chapel. After an hour or so, two workmen came in to the chapel and went over to the area by the table. They were discussing some painting that had to happen, so I sort of tuned them out. My ears perked up, however, when I heard them mention a water leak which had caused significant damage to the structure. It turns out they’d had issues with parts of the extremely high ceiling falling down onto the floor.
The table was placed on that exact spot to block people from standing or sitting there. The “Do not move this table” sign was intended to ensure nobody was injured by falling debris.
One could sit around and argue that the sign was badly written, leaving out critical information (“Sit here and you will DIE!”), or that something else should have been used to block off that area. (Police tape, orange snow fence, flashing lights, Albanian dwarf mimes)
Those arguments are missing the point. The sign made perfect sense to those who wrote it and there was a darn good reason for the sign being there.
We constantly run in to similar situations with the folks we’re building software for. What seems an utter mystery to us is utterly clear to our clients, customers, stakeholders, whoever. Moreover, sometimes there’s something really important behind those things that seem, to us, stupid and incomprehensible. We’re outsiders, and we’re missing the critical context.
Spend the time asking “Why?” with those whose problems you’re trying to solve.
You may save yourself getting schwacked on the head with debris.
Go sign up now for the Software Engineering 101 conference.
What is the SWE 101 conference? Go read my previous post on it!
UPDATE! Registration is open here.
A few great speakers and I are working to put on a unique event on Wednesday, 9/23: Software Engineering 101.
This is a one-day, FREE event targeted to help you build your skills in how you build software. This isn’t about learning the basics of Silverlight, WPF, or </insert_new_tech_of_day>. Rather, this conference will help you understand how to build software that’s better designed, more maintainable, and more testable. We’ll spend the morning on fundamentals around object-oriented programming, the SOLID principles, and a few other important skills. The afternoon will be a hands-on Test Driven Development workshop putting those skills to use.
Here’s what we’ve got on the agenda:
| Time | Session | Speaker |
| 8:15 – 8:20 | Intro | |
| 8:20 – 9:30 | Principles of Object Oriented Programming | |
| 9:35 – 10:45 | SOLID | Jon Kruger |
| 11:00 – 11:15 | Understanding Code Metrics | Jim Holmes |
| 11:20 – 12:30 | Production Debugging | Scott Walker |
| 12:30 – 1:30 | Lunch | |
| 1:30 – 5:00 | Hands on Test Driven Development | Leon Gersing and others |
| 5:00 – 5:15 | Closing remarks |
The event will be at Microsoft’s office near Polaris Parkway in Columbus. I’m working on sponsorships to pay for light food and drink, but that may or may not pan out. Lunch will likely not be provided, but we’ll take an hour so folks can get out to eat at one of the many places in Polaris.
You likely have noticed this event’s on a weekday. I purposely targeted a work day because lots of community folks already give up significant amounts of their weekend time – plus I’m interested in seeing if we can reach out to a new set of attendees who might not otherwise be able to attend.
I’ll have a registration site up shortly, so stay tuned for details on how to sign up.
In the meantime, spread the word and block off Wednesday, 9/23/09 on your calendars!
Here are reviews for two books I’ve recently run through.
Stand Back and Deliver by Pollyanna Pixton, et. al. Pub by Addison Wesley, ISBN 0321572882.
This is absolutely one of the best career-shaping books I’ve read, ever. It’s concise, it’s easy to read, and it’s chock full of some seriously vital things you need to get solid in your head as part of successful software delivery.
I found a wide range of great wisdom in this book, some things which were new, and some which were things I'd let slip. There's insight on teams, personnel, risk management, and lots of other goodies. It's all laid out in short, well-written chapters authored by folks who've been around the block a number of times.
While all of the book was extremely helpful, perhaps one of the most valuable things I found was their “Purpose Alignment Model,” (PAM) a simple quad chart with market differentiation on the Y axis and mission criticality on the X. The quads break down in to categories of Who Cares, Partner, Parity, and Differentiating. The authors walk the reader through clear, powerful exercises to help you focus on making decisions that will help you succeed at differentiating you and your company from your competitors – but retaining some focus on things you need to stay in parity with them.
I found all the discussion around the PAM highly stimulating because it fits so well with my fundamental beliefs in being adamant and aggressive about Lean software development. The section on Context Leadership Model is probably just as important: it helps you assess a project’s uncertainty and complexity. Again, the authors do a tremendous job showing you utterly practical, real-world applications of this.
I can’t recommend this book enough if you’re at all interested in improving how you decide what to build, and how you go about it.
The Myths of Security by John Viega, pub by O’Reilly, ISBN 0596523025.
This is a wonderfully contrarian view to much of the information we are fed regarding security. Viega brings a much-needed skeptical view to many of the things we as consumers and workers in the IT industry are fed. He skewers everything from antivirus to identity theft and takes a lot of effort to lay out his propositions around how bad guys are driven by money.
I got a bit weary of the not-quite-shilling for McAffee, the company Viega works for, and there were a couple technical howlers (a server-side application which required 200 servers simply “because it was written in Java”). Those irritants aside, it really is a great read which, whether you agree with his points or not, should make you re-evaluate how you look at security.
Books which make you think are always a Good Thing.
I gave my “Three Tips to Improve Your Process” talk at devLink last week. You can find the deck here.
Thanks to the folks who attended! There was a great turnout and I got some great questions from the audience. I’ve already slightly tweaked my deck to reflect some of those questions. Feedback, FTW!
Once again, John Kellar and his crew put on a fantastic conference, and once again, I spent the majority of my time hanging out with my friends in the Open Spaces sessions. (Can we please stop calling it “Open Spaces Technology” already?) I did catch two great “regular” sessions, one being Bryan Hunter’s Lean Workshop and the other Rick Kierner’s TDD in SharePoint.
I also got a much needed lift from a couple close friends who gave me some good feedback and tough love. Plus, I got to sit on a Dot Net Rocks panel discussion with some neat folks. (Separate post on that soon.)
The 12-hour round trip drive was greatly sped by having Leon in the car and I’m fairly sure we solved sixty or eighty problems including the Golbach conjecture, the Higgs mechanism, and a host of other pressing problems. Culture change in people who actively resist change thwarted us, but we did finally figure out we need to stop giving those people power over us.
Overall, it was an awesome trip. I’m looking forward to returning to devLink again next year. After all, it is the region’s second best conference. (We all know what the region’s best conference is!)
I was at eRubyCon this last week, courtesy of Joe O’Brien and the great folks at EdgeCase who invited me to speak.
This was my first conference outside the .NET arena in years (excluding CodeMash) and I’m kicking myself for not doing this more often. I got some great insights on different ways to solve problems, and I met some amazing folks who inspired me to get to work on fixing a few things in my life that need addressing. I also got fired up about a few neat tools and some changes to our environment at work. (CodeMash is awesome for this, but as an organizer I get little or no time to actually participate in it.)
I gave my Leadership 101 talk as the first session of day 2. This is the second time I’ve given this talk, but it was in a completely different format than the 20 minute talk I gave at KalamazooX. KalX was amazing (and I hope I get invited back there!), but the longer format of eRubyCon gave me a chance to flesh out a few points. I also mixed in some examples from my background to lend some detail and color.
I always feel weird talking to a crowd about leadership because I don’t pretend to be a master of it, but the audience there was wonderful to speak to, and I got some nice feedback.
The slide deck is my usual funky style: 14 slides total, two pictures, one number, and (aside from the opening quote) six words total, three of which are repeats. There are even a couple blank slides just because. The deck’s here and there are some notes on it, but the best resource is really the Leadership 101 blog series that inspired the talk.
eRubyCon has been one of the best conferences I’ve ever been to. I’m definitely attending next year regardless of whether or not I’m on the speaking docket. It was an awesome weekend!
UPDATED: It’s now December, 2010 and I’ve got another open position on my team! Everything below still applies. Contact info is at the bottom, or use the link on the blog’s sidebar. I’d love to talk with you if you’re interested!
Telligent is expanding our QA/testing team and we’re starting the process of looking for passionate, detail-oriented folks who might be a fit for the team. You’ll be working for me in my new role as the QA Team Lead, and you’ll be testing our neat products like Telligent Community, Telligent Enterprise, Telligent Analytics, plus a host of cool add-ons like our Mail Gateway and SharePoint integration products.
I don’t have a formal job description yet, but frankly, most job descriptions stink or don’t match reality. Here’s my unofficial, completely unapproved description of what you’ll be doing:
Below are some of the tools we’re using or exploring in our QA work right now. I’m all over using any tool that will bring value to our work, so if there’s something you’ve had success with then let me know.
What you’ll need to bring to the table:
Notice I didn’t mention much about specific skills? What you’ve got in your head and heart are far more important to me. That said, it would be helpful, but not required, if you’ve got some exposure to the following:
Telligent’s located in Dallas, but we have remote workers scattered all over the country and a few overseas as well. I’m happy to work with remote folks, but you’ll need to demonstrate that you’re able to be productive from a home office.
You’ll be working for me, so you may want to do a little digging around the blogosphere, Twitter, and the region’s dev community to see if that’s for you or not. I’m strong coffee with strong opinions that I’m happy to change when a well-thought debate is put forth. I care deeply about my work and I care even more deeply about my teams. Look up some folks who’ve worked for me or with me and get their opinions. (Steve, James, Brian, Todd, Nate, Sean, Dave, Leon) I didn’t ask them if it was OK, but I think you’ll get varied, honest feedback from them.
Still interested? Drop me an e-mail with your resume: JHolmes AT Telligent DOT com. Feel free to drop me a note via the contact link on the blog’s sidebar, too.
Tom DeMarco, author of the seminal book Peopleware has written a short, interesting article Software Engineering, An Idea Whose Time has Come and Gone?
DeMarco’s article is really around engineering as it refers to controlling the process of creating software, not the actual software construction itself. The article’s short and doesn’t start any in-depth discussion, but the general point is awfully good: working too hard to control the process of software construction is a bad thing. A great quote from the article:
For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.
We can’t use this as an excuse for being sloppy with our clients’ time or money, be those clients internal or external. That said, the points DeMarco makes line right up with my own beliefs:
DeMarco’s article is way too short, and I really wish he’d provided more detail on the metrics and measurements he’s decrying – but I think there’s some good conversation starters there.
Subscribe (RSS)
The Leadership Journey
