I’m working with a company that uses Lotus Notes. It’s been more than 10 years since I’ve had to use Notes and it’s as bad as ever. It’s probably the worst piece of software ever released by a major company. The worst feature — well, it’s hard to pick a worst feature, but one of the worst features — because I have to deal with it dozens of times a day — is the way Notes makes me reply to email. I can’t just click Reply and start typing. When I click Reply, I get a dropdown list of options and have to select one: – Reply – Reply with History – Reply without Attachment(s) – Reply with Internet-Style History The godawful thing about this is that default options for email work 100 percent of the time. I always want to reply with history and without attachments, so why give… Read more →
EppsNet Archive: Software Development
The Average Software Developer
The average software developer reads less than one professional book per year (not including manuals) and subscribes to no professional magazines. These developers are not developing or advancing themselves professionally. About 75% of these people do not have a degree in computer science or a related field. They learn by trial-and-error and on-the-job training, which means that they risk learning other people’s bad habits rather than industry best practices. This method of professional development perpetuates ineffective, inefficient practices that hinder the success of software projects. — Construx.com Read more →
Changing Requirements
The most common reason for software project failure is attributed to requirements issues – badly defined, not stated correctly, changing requirements, etc. — “Tips for Discovering Requirements” Any project I’ve done that lasted longer than a day had changing requirements. If your development strategy only works with an unchanging set of requirements, you need to rethink your approach . . . Read more →
James Bach on Software Testing
Jerry Weinberg has suggested that “it works” may mean “We haven’t tried very hard to make it fail, and we haven’t been running it very long or under very diverse conditions, but so far we haven’t seen any failures, though we haven’t been looking too closely, either.” In this pessimistic view, you have to be on guard for people who say it works without checking even once to see if it could work. “No user would do that” really means “No user I can think of, who I like, would do that on purpose.” Who aren’t you thinking of? Who don’t you like who might really use this product? What might good users do by accident? In general it can vastly simplify testing if we focus on whether the product has a problem that matters, rather than whether the product merely satisfies all relevant standards. . . .… Read more →
Managing Teams
Instead of “managing” the process in the traditional sense, management can help a lot more by: realizing that it is the teams that will discover and make the improvements, not management, giving teams the responsibility to manage and improve their own process as well as the freedom and authority to do so, establishing an environment that actively encourages teams to be totally honest about their problems and impediments, listening to what the teams say they need and respond to those needs, observing teams in action instead of just collecting numbers, providing useful feedback to teams instead of instructions or pressure. — Steven Gordon Read more →
Playing the Expert Game
If . . . you are able to get important things done you are seen learning things on your own you are seen trying to do things even if you aren’t sure how you share freely the things that you know you don’t hide your ignorance, but also don’t rest on it you honor what other people know you know more often than not how to find out what you don’t know you know how to ask for help you offer to help people on their own terms Then . . . no one will care whether you succeed by learning or succeed by already knowing no one will care if you mess up occasionally because they assume you learn from it no one will mind if you forget (or don’t know) any given fact or method at any given time you will be treated as if you’re smart and… Read more →
Torvalds on Specs
A “spec” is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate. And I have seen _lots_ of total crap work that was based on specs. It’s _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality. So there’s two MAJOR reasons to avoid specs: – they’re dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada. None. It’s like real science: if you have a theory that doesn’t match experiments, it doesn’t matter _how_ much you like that theory. It’s wrong. You can use it as an approximation, but you MUST keep in mind that it’s an approximation. – specs have an inevitably tendency to… Read more →
Schedule Crunching
Many wise people have said that what you put your attention on is what you will create around you. This is true in project management. If you concentrate on meeting the plan and slipping when big problems arise, you will, at best, ship on time, and more likely, you will ship late. . . . To change your results by changing the way you look at how your team uses time, you must put your attention on how to make tasks take the least time possible. Replace “sticking to the plan” with “looking for ways to decrease the time spent.” — Michele McCarthy Read more →
Informed Consent
I work in the IT department of a health care organization. I’ve noticed before that health care professionals are much better than IT professionals when it comes to setting the expectations of customers. Last week, I found a handbook around the office called Risk Prevention Skills: Communication and Record Keeping in Clinical Practice. Substitute “customers” for “patients” and “software development” for “medical care” and you can apply the same advice to IT: Some patients are unreasonable in their expectations of medical care. . . . If a complication does occur, the patient or family with unreasonable expectations will usually conclude that someone must have done something wrong and should be blamed. The only way to correct unreasonable expectations is to accurately explain to the patient, before care is provided, what problems may be encountered. An accurate description of the range and likelihood of possible outcomes, and the reasons why an… Read more →
I Hold in my Hand a 63-Page Requirements Doc
I hold in my hand a 63-page requirements doc . . . We spend a lot of time reworking the requirements doc to reflect the reality of the system that we’re actually building. We also spend a lot of time reworking all the docs that derive from the requirements doc — design docs, UI docs, test plans, etc. — to reflect the changes in the requirements doc. Another way to think of this is that the project is driving the requirements, rather than the requirements driving the project. So why did we create all these incredibly detailed documents in the first place? We have a vast collection of well-documented ignorance . . . Thus spoke The Programmer. Read more →
Declaration of Interdependence
We increase return on investment by making continuous flow of value our focus. We deliver reliable results by engaging customers in frequent interactions and shared ownership. We expect uncertainty and manage for it through iterations, anticipation, and adaptation. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference. We boost performance through group accountability for results and shared responsibility for team effectiveness. We improve effectiveness and reliability through situationally specific strategies, processes and practices. — Declaration of Interdependence Read more →
Rethinking Success and Failure
There’s an old saying that you get what you measure . . . I recently asked a colleague whether he would prefer to deliver a project somewhat late and overbudget but rich with business benefits or one that is on time and underbudget but of scant value to the business. He thought it was a tough call, and then went for the on-time scenario. Delivering on time and within budget is part of his IT department’s performance metrics. Chasing after the elusive business value, over which he thought he had little control anyway, is not. — Helen Pukszta, “Rethinking Success and Failure in IT” Read more →
Don’t Argue About Things That Don’t Exist
Some ideas. . . . Don’t argue about things that don’t exist, like whether Save buttons should do this or that. Instead, code or prototype it and then team members use it themselves. You’ll be able to tell if it could be better when you use it instead of talk about it. . . . One of the biggest blockers to team greatness is that members of team will have really good team diagnoses but they don’t say them out loud. So nothing can be done with the idea. You gotta say your great ideas out loud. . . . Stay out of the content. The real issues are not about UI and architecture. Those are just the excuses to act out team neuroses. . . . If you resolve the interpersonal issues you won’t feel like you have UI or architecture issues. Processes and planning will… Read more →
Got a Job
After three months on the dole, I got a job offer from the IT director of a local non-profit healthcare association here in Orange County. I start next week. As Gerald Ford used to say, “Our long national nightmare is over.” It’s a small IT group — 8 people, including the director. I’ve got to admit I’m a little burned out on big corporate IT shops. I got out of hands-on programming and into leadership roles because I thought I could do a better job than the people I saw doing it. I wanted to develop teams that got things done using their skills and their collective intelligence, but in practice, you typically get locked into some corporate process standard. A process may be good for delivering consistent results, but they may not be consistently good results. Like at McDonald’s, every Big Mac is just like every other Big Mac… Read more →
Offshoring: What Can Go Wrong?
You might wonder whether the Linux operating system provides evidence that offshoring can pay off. I had often wondered about this point myself, so I put the question to Linus Torvalds, founder of the Linux project. Torvalds replied that the two models of software development aren’t comparable: I don’t think the Linux model works for offshoring in the commercial sense, or really ends up even being very relevant. The problem ends up being communication and the mental model pretty inherent in offshoring. My belief is that when you say “offshoring,” you very much mean “control the project on one shore, work on the other.” That is, the implication of the offshore work being “subservient” is very much there in the notion of offshoring. In contrast, the Linux model (and open-source in general) is that there’s no one-sided control, and that when work gets done overseas, it gets done because it… Read more →
Advertisement for Myself
I was laid off recently by a mortgage bank here in Southern California. Times are tough in the mortgage business, as you may have heard. First, some tips on how not to do a layoff: Call the layoff a “rightsizing,” which suggests that there was something “wrong” with the people who were let go. (Actually, the company I worked for has already announced another “rightsizing” in which 1,000 more people will be laid off over the next few months. They just can’t get these “rightsizings” right.) Overnight a layoff information packet, including a 20-page severance agreement, to the home of laid-off employees, asking them to sign and return it via the enclosed UPS envelope. Don’t enclose the UPS envelope. The next day, overnight a second packet to employees’ homes, containing the UPS envelope and a letter correcting phone numbers, email addresses and other misinformation in the previous day’s packet. Include… Read more →
Why I Got Into Management
My first 10 years in the software business, I had great managers. They did the management thing and I did the programming thing and we got great results together. Then, after the dot-com boom torpedoed industry hiring standards, I got tired of working for managers who should not have been allowed anywhere near a software project, people who were not fit to direct a professional software developer to a table at the Olive Garden, much less direct their activities on a complex project. I couldn’t possibly have continued to work for people like that — it just made a mockery of all the work I’d done over the years to actually learn something — but I still miss being a developer . . . Thus spoke The Programmer. Read more →
Rather Disrespectful
Another aspect of respecting people is the idea that the process that the team uses to generate value is owned by the team. The process is what the team uses to achieve its goals. By the time things get formalized, it rapidly morphs into a situation where the team is a tool that the process uses to achieve its goals. That’s rather disrespectful of the individuals involved. It doesn’t leverage their capabilities and strengths and insights. — Tom Poppendieck Read more →
Antipattern: Exactly on Schedule
I work with a company that has the following set of milestones in its standard project methodology: Vision/Scope Complete Requirements Complete Design Complete Definition Complete Build Complete Test Complete Rollout Complete I’ve noticed an interesting pattern at the weekly enterprise status meetings: a significant number of projects report being exactly on schedule for each milestone — not one single day ahead or behind! — until they get to rollout, at which point they suddenly go several months late. Some things can be faked and some things can’t. As long as you have milestones that can be met simply by declaring them done, or by signing off on a document, you can always hit them on time. But when it comes to putting actual working software in front of a customer, that’s when you really have to deliver the goods, and that’s when the milestones start getting missed. This is a… Read more →
Schwaber on Scrum
You know that Scrum is gaining traction when all of the things that have been ignored to date become painfully obvious and you just wish you had never started the whole thing. This often happens within three months. At that point, the only thing that pulls me through is looking back and realizing that things have actually improved. — Ken Schwaber Read more →