Friday, August 28, 2009
Alan Skorkin reminds us that much of what drives current software development process came from the more general study of process for all kinds of work, including manufacturing. When you decide to adopt a particular process, you do so to reach a goal and for that vast majority of businesses, that goal is productivity - more profit per time period. (For a few very small operations, less time period to earn the profit / income sounds far more humane, but is still based on a desire for higher productivity.) Whenever you adopt a process instead of just telling your staff to do whatever you want, it's because you don't think they would be as productive left to their own devices as they would be under the direction of the process. As Alan points out, there are two very different thoughts behind this basic position. One says that workers are lazy and shiftless. They'd rather chitchat, smoke, or daydream than produce what management wants them to produce. Processes built on this thought are all about measuring and controlling and proving that people have or haven't done what they should have done. The second, christened Theory Y in contrast to the first, which got dubbed Theory X in order to tell the two apart, says that workers are much happier when they know they are productive, and need management to help them achieve productivity as a co-operative goal. Processes built on this thought are full of collaborative work and empowering and the like. He goes on to draw some specific conclusions about Lean that I will leave aside. I think it's useful to look at the process you work with day to day and ask yourself - is this process founded on Theory X or Theory Y? What image does the management at your firm have of the workers at your firm? Does process control them or support them? Is the motivation for workers assumed to come from inside themselves, or to be imposed by management? No matter what management says about what developers can and can't do, the process you work with will tell you their founding principle. It might be an eye opener to think about it like that. Kate
Wednesday, August 26, 2009
It wasn't long ago everyone was talking about a whole new way of working. It started with telecommuting in the 90's, but spread in this century to something far bigger. Remote work as a way of life, virtual teams, outsourcing, offshoring ... the scale just kept growing and the savings for companies appeared to be at least partly met by happy staff, whether that was a guy in the city who didn't have to spend 90 minutes each way in traffic, or a guy who was able to keep living in his small town while working for the big city firm so far away, or even a guy in a developing country who was able to earn more than his neighbours and follow the lure of high tech and problem solving at a time when no firms in that country were offering those jobs. I know many people in the big cities and the developed countries lost their jobs to those people, and I know it wasn't always simple to find traditional employment once the world of work started to change. Still, the world and the way many people in it earn a living changed and will not be changing back. That said, in the mid 90s everyone I knew who was associated with any of this "new way of working" had come to realize it wasn't just a fire and forget sort of thing. You had to communicate a lot. And while technology made some ways of communication simple and cheap, so that video calls and conference calls and instant messenger and desktop sharing and so on are all vital, it couldn't do it all. You have to get face to face still, and you have to do it regularly. I recently finished a 10 month contract for clients three thousand miles away. I did the vast majority of the work from here, and had phone calls and livemeetings many times a week. But every 4 to 6 weeks I got on a plane and I went there. And wow, the work we got done in those few days! Mini hallway meetings, lunches, dinners -- I typically could "touch" half the project participants in just two or three days, and solve seemingly intractable problems by going to people's offices and listening to them and looking at their body language and telling them they could trust me or asking them what the real problem was. It made such a huge difference to the success of the project. I didn't get paid for the time I spent travelling to them, or the nights spent away from my family, but I gladly invested that time to make everything go smoothly and to be a successful remote worker. Some other folks have noticed this too, and in a far more systematic way. How's this for a conclusion: "... common workplace-relationship problems, such as broken commitments, mistrust
and misrepresentation of information, occur more than twice as often with
virtual teams, as opposed to teams located in the same building. " Yikes! Apparently it's partly because things we do when we're upset with people work well if you see if each other regularly, but make things worse if you're apart. Or this useful summary: "teams are a lot more effective when they're working with their friends in
another country than when they're working with those stupid offshore idiots
who never understand our designs or requirements." So in that context, what could be a worse way of saving money than lowering the travel budget to zero and not letting people visit each other any more? Yet that is exactly what's happening in a lot of companies. If it's happening in yours, do something about it. You need to visit your colleagues. If not, when your projects go pear-shaped, you may find the whole concept of virtual teams gets thrown out with it. And that would be a real shame. Kate
Monday, August 24, 2009
I am pleased to learn that at least one of the sessions I submitted for Tech Ed Europe in Berlin has been accepted: The Windows API Code Pack: How Managed Code Developers Can Easily Access
Exciting New Vista and Windows 7 Features
Accessing new Windows 7 or Vista features
is a challenge from managed (.NET) code. The level of interoperability required
is out of reach for many developers. The Windows API Code Pack for the Microsoft
.NET Framework is a sample library you can use in your own projects today that
provides access to new user interface features (taskbar jumplists, libraries,
sensor platform and more) as well as "behind the scenes" features that make
your applications more aware and responsive (restart and recovery, power
management, and more.) Discover a shortcut to Windows 7 and Vista development
for Microsoft Visual Basic and Visual C# programmers and how you can get
involved. Now comes the logistics fluffle of getting everything booked, telling "my" teams I'm going, and possibly picking up some other talks or panels or whatnot while I'm there. I'm looking forward to it already! I love Tech Ed Europe - it's such a well run show and the other speakers are a delight to spend time with and learn from. The energy is always good and on top of that the destination is fabulous. I adored Barcelona, so now it is time for Berlin to show me what she's got. What a week we've picked to be there! You can still register at a discount. See you there! Kate
Saturday, August 22, 2009
I've done several Tech Ed talks, in Europe and the US, in which I've demoed lambda expressions, a new language feature coming in C++0x and implemented in Visual Studio 2010. If you missed your chance last year to watch my Tech Ed Europe talk, it's still available on page 3 of the "last year's highlight's" page. But that's 80 minutes and covers more than just lambdas. If you would be up for investing a tenth of that time, try this Channel 9 piece featuring Thomas Petchel. He's obviously VERY familiar with the STL and he illustrates perfectly how writing dinky little functions to initialize arrays can be tedious and time consuming, and how lambdas make them faster. If you watch that and like what you see, go ahead and give my Tech Ed talk a listen as well. Kate
Thursday, August 20, 2009
Recently I came across an article suggesting how a good developer should comment their code. This was aimed at those writing SQL scripts, but that doesn't particularly matter. The rules were the same ones I lived by in the 70's and for a long time since then. For example, at the start of each file there should be a modification history, like this: /* Title: 002 - Setup SQLCMS.sql Purpose: Setup the various components for SQL CMS Version: 1.1 Modification History: 04/30/2009 - Buck Woody - Initial Script Creation 05/15/2009 - Buck Woody - Added MAPS load scripts
I copied Buck's since I don't have any like this myself kicking around. And why not? Because VSTS and TFS take care of that for me. Who changed it, what they changed, and why is all available in the repository. Duplicating it in the file itself just gives you another task to forget, and another pair of locations that might get out of sync. So I don't do these any more. There's another kind of comment that we all used in the 70's and 80's and that was the "explain your names" comment. When you only had 8 characters to work with, you needed a big block of comments that told everyone that NPPLINV was Number of People Invited and CIDMNEW was Calculate Interest, Daily Method, New or whatever. But we don't have name length restrictions any more. So why do I still see this sort of thing: Dim ClientName as String ' Variable to hold name of client Dim ClientBirthDate as Date ' Variable to hold birth date of client Dim ClientRepID as Integer ' Variable to hold ID of client rep
(Don't believe me? I saw this very code yesterday in a VB6 app I was debugging.) As Jon Torresdal points out, if you choose your function names and variables well, you don't even need those single lines that explain funky-looking calculations. Extract your weird stuff to a function, even if it's a single-line function, and it explains itself. You can see a similar approach, though comments are never mentioned, in Justin Etheredge's post about isolating logic into little functions. So let's see, no comments at the top to explain what the file is, no comments after each variable to explain its strange and abbreviated name, no comments before funky calculations because they've been refactored into single line functions ... well what comments even remain, then? Well there's commented-out code - but I have a rule against that. There's this sort of thing: 'only update confirmed date the first time it's confirmed If DateConfirmed = Nothing OrElse DateConfirmed = New Date() Then DateConfirmed = Today End If Sometimes these comments are there because the developer wrote the comments first, as pseudo-code, then filled in the code. Other times they are just an attempt to translate the code into English for the reader. Does it help? Well, maybe. But comments are becoming less and less important as time goes by. Interesting.
Kate
Tuesday, August 18, 2009
I've read a few articles lately that have no praise for the praise sandwich. If you haven't heard that name before, it refers to something like this: Joe, I really like the confidence and energy you bring to your work. But yesterday's outburst was unprofessional and frankly unacceptable. It's the sort of thing that could get you fired. But you're such a smart guy that I'm confident you'll never do anything like that again. You're an important part of the team and we're all glad you work here.
You start out by saying something nice, then criticize, then say something nice again to end the meeting on a positive note. So what's wrong with that? Well partly it's all the "but" in there. I've talked about that before. There's more to it, though. Esther Derby says it "tends to erode trust in the feedback givers intentions, and once that's gone,
there's not much chance any useful information will get through" which is a very good point. Her advice about how to deliver criticism is very good, most especially "don't sell past the close." Art Petty says it is "insulting to the receiver and borderline deceitful" and is really about making the criticizer feel better, not the recipient. Of his tips, I especially like "link the issue to business impact" - one of the real strengths the boss brings to any situation is the extra information about the consequences of errors. I have found over the years that people who write code all day really don't see a problem with broken links or bad images on live websites, because it still works and it's not like there was a code problem. That's just one example of course, but if you want to change someone's behaviour, it's important that they actually understand why it's truly a problem. I couldn't count the number of times I've had to tell someone they really screwed up. I know there were times it was as little as two words. After establishing the facts of the matter, I once just sighed and said "Not cool." That was all that employee needed to be told. I've also had very long and heated conversations that did not result in changed behaviour. These days I go for shorter over longer. And I don't do sandwiches. Kate
Sunday, August 16, 2009
I've mentioned the sensor improvements in Windows 7 a little bit, but they really deserve a good long blog post of their own. Luckily for me, my fellow RD Sondre Bjellås has written it .
This is a handy demo board that does light as well as position (think Wii) with some buttons you can push. Sondre covers where to get the board, where to get the drivers, and a really simple sample app to get you started. Then you're going to want the Windows 7 Training Kit - the Hands On Labs have some fun demos. Check it out! Kate
Friday, August 14, 2009
What language do you think this post by Jeff Atwood refers to? There are over 220 billion lines of <language> in existence, a figure which
equates to around 80% of the world's actively used code. There are estimated
to be over a million <language> programmers in the world today. Most impressive
perhaps, is that 200 times as many <language> transactions take place each day than
Google searches - a figure which puts the influence of Web 2.0 into stark
perspective.
Wow. 220 billion-with-a-b? B as in Business? As in Business-Oriented-Language? You know, the only thing I like about COBOL (and I have written precisely one COBOL program in the three decades I've been paid to program) is that it made it possible to have a language called SNOBOL. The comments are full of folks who are maintaining 30 year old apps with a million lines of code, but the thing about billion-with-a-b is that you need 220,000 such folks to hit that number, and what's more as Larry O'Brien points out 20 years ago folks said there were 30 billion lines, and while I can agree that existing apps are being maintained, I don't think there are 7 times as many lines of COBOL out there now as there were at its peak. But that's not my point. My points is that when you live at the leading edge, the bleeding edge, you forget a really important rule: edges are thin. The handful of us who are moving our apps to 4.0 now, who are complaining about an incompatibility between our Visual Studio 2010 beta and our Office 2010 beta, who are using a language invented this century, are dwarfed by folks who have been using the same tools and the same languages throughout their entire career. These people are invisible because they don't come to conferences, attend user group meetings, buy programming books, or read blogs. Heck, at one of my clients, the AS/400 guys sat off to the side and behind a little wall of cubicle partitions that was double the height of everyone else's. Really. They also never came to all-hands meetings and were exempt from the company-wide .NET training I delivered. So do these "dark matter" developers matter to the "bleeding edge" developers? I think they do. For one thing, when you have your shiny and exciting idea to change everything about the way some software works, these guys can cancel your whole project with one or two sentences. For another, they are likely the only ones who understand the data format, the business rules as actually coded, and the special cases that come up every 15 to 20 years. Not to mention they can work the text editor. If you find yourself in a situation with some COBOL (or equivalent) developers in it, don't ever tell them you didn't think they existed any more. That's my tip to you. Kate
© Copyright 2024 Kate Gregory
Theme design by Bryan Bell
newtelligence dasBlog 2.3.9074.18820 | Page rendered at Tuesday, October 08, 2024 1:28:22 AM (Eastern Daylight Time, UTC-04:00)
|
On this page....
Pluralsight Free Trial
Search
Navigation
Categories
Blogroll
Sign In
|