The truth is an important thing when you want to get to the bottom of something and having the truth is the most important part of making decisions. This isn't just about programming but everything in life. The problem is that the truth is often at odds with tact.
Things to remember about the truth:
Sometimes, the truth will make people laugh.
Sometimes, the truth will hurt.
Sometimes, the truth will set you free.
But always, the truth will piss someone off.
Tuesday, December 23, 2008
Sunday, August 24, 2008
Best is the Enemy of Good
Continuous Improvement
It was encouraging to me that my company decided to host a continuous improvement activity for the development group in our IT shop. If you've never done one of these before, it's related to process improvement and such things as LEAN and Six Sigma.
What I didn't understand before the activity was that LEAN is not about solving the root of the problem, it's about trying to streamline and make more efficient all the peripheral things in the total process. For example, in our workshop we identified that some of the production support load we get is from misdirected requests that should have gone to a different group. So we're taking steps to better educate users and other support personnel so they can reduce this source of inefficiency.
However, I asked about the fact that the real source of production support loads is often poorly built software, and it was accepted by the session consultant that indeed, LEAN does not always address the root problem. The example he used was from when he worked with a group that performed drilling on a designated area. Improved productivity could have been had by using a faster drill or technique, but that was not what LEAN was about. It was instead about all the particulars of the process leading to, during, and following the drilling, and removing wasteful elements in these phases of the total effort.
Another Adage
Anyway, improvement is good in any space, so I'll take what we get out of it even if it means the software we're using is still seriously flawed.
One of the interesting things emphasized during the workshop, however, was:
It was encouraging to me that my company decided to host a continuous improvement activity for the development group in our IT shop. If you've never done one of these before, it's related to process improvement and such things as LEAN and Six Sigma.
What I didn't understand before the activity was that LEAN is not about solving the root of the problem, it's about trying to streamline and make more efficient all the peripheral things in the total process. For example, in our workshop we identified that some of the production support load we get is from misdirected requests that should have gone to a different group. So we're taking steps to better educate users and other support personnel so they can reduce this source of inefficiency.
However, I asked about the fact that the real source of production support loads is often poorly built software, and it was accepted by the session consultant that indeed, LEAN does not always address the root problem. The example he used was from when he worked with a group that performed drilling on a designated area. Improved productivity could have been had by using a faster drill or technique, but that was not what LEAN was about. It was instead about all the particulars of the process leading to, during, and following the drilling, and removing wasteful elements in these phases of the total effort.
Another Adage
Anyway, improvement is good in any space, so I'll take what we get out of it even if it means the software we're using is still seriously flawed.
One of the interesting things emphasized during the workshop, however, was:
Don't let best be the enemy of goodThis was meant to keep us from succumbing to paralysis by analysis. I've heard this same sentiment in another quote from Patton:
A good plan now is better than a great plan ten minutes from nowI can't disagree with the gist of those platitudes, but there is a fundamental problem facing most software teams that try to use that quote for enlightenment. What if the battle they're fighting isn't between good and best, but good and mediocre or poor? My version of the quote is therefore:
Best is the enemy of good, but don't confuse good withRemember: making software is easy, but making it right is hard! It is too easy to lower your standards and say "good enough." But as complicated as software is, the truth is that "good enough" is probably "bad enough" since corporate software is often poorly designed and poorly tested. Even if it is good enough, chances are you'll have to change it, and good enough can quickly become not-so-good.
mediocre
Sunday, June 29, 2008
Project Management - Friend or Foe?
The concept of project management is becoming more popular, thanks in part to the efforts of the Project Management Institute and some institutional desire to better organize and control projects. The concept isn't new, but classically the project manager in corporate projects was someone that was either part of the delivery team and was expected to manage everyone or was a manager that may have had supervisory control over the project team.
The official position of project manager (PM) as it has been explained to me is one in which the PM may not have managerial control of project subordinates and must use persuasion and communication to keep the project on track and the team members delivering. The contemporary PMI definitions make the PM responsible for several project guidance and reporting deliverables, and providing these represents actual overhead costs. Although some will say the effort involved in being a PM is not enough to justify it as a full-time role, I would argue that it could be, depending on the project and complexity.
Resource Management
In my past experience with PM work, one of the things I've struggled with is when members of the team are expected to materially participate in the PM duties. If your projects are anything like the ones I've been on, then you're familiar with the corporate American tendency to want things as fast as possible. Especially with software, it shouldn't take long because software is just a bunch of typing and how hard can that be?
But as the blog has noted before, software is only easy if you want to produce garbage. It requires real focus and a mental investment to create effective software, and when the programmers have to also spend time delivering project management deliverables, the programmers are forced to spend less time on analysis, design, construction, and testing efforts. That often leads to frustration for both the developers and the PM.
It is not wrong to expect some developer input in PM deliverables, but certainly this is overhead that needs to be considered lest the staff feel they are once again forced to work unpaid overtime to produce something other than actual product.
PMs versus Developers, Users, and Analysts
The overhead of PM work distributed among the team can at least be managed. There's a more serious disconnect that can happen when it comes to the subject of determining project quality. Scott Ambler's written a little about this in his blog at Dr. Dobbs Journal.
To summarize, Ambler ran a survey that included questions about how project members define IT projects a success. Although the survey sample was modest (Ambler got roughly 600 responses) some of the results alarmed him. He found that:
He conceded that the sample size didn't include more business stakeholders and so the statistics might need to be taken with a grain of salt, but the general thought does make sense. The goals of the PMI would certainly stress "on time and on budget" as measurable goals. Software quality, on the other hand, is harder to measure. Because of that, it's also hard to estimate the effort needed to reach it in planning phases. The concept of quality is also subjective and that doesn't help matters.
Maybe Software isn't a Project
Here's another idea. Software is a living document. It changes over time and as long as people are using it and maintaining it, it's never done. Does that sound like something you can harness with a beginning, middle, and end?
George Stepanek, the author of Software Project Secrets (Apress ISBN10: 1-59059-550-5), notes that the formal project management methodology is not a good match for software development. Static phases like initiation, planning, and concluding are more a match for traditional waterfall software methodologies than newer "agile" methodologies. Although I'm not as down on waterfall as most are (all waterfall did was win WWII, send a man to the moon, and get the space shuttle into space, among other things), there's no denying that regardless of approach, software is a series of iterative feedback loops between developers and users that extends far beyond a stated project period.
Software Management and Project Management Must Coexist
Neither software nor project management are going away anytime soon. Software has become a part of our everyday lives and project management adds appreciable value in helping to "divide and conquer" the body of work corporations do. But developers and project managers have to continue to understand the disconnects between traditional project approaches and software development and also make strides in measuring software quality. If this does not happen, then the industry will continue to be filled with projects that are only successful on the surface. It will continue to be a place that graces a few with bonuses while leaving behind train wrecks for others to clean up in the late hours.
The official position of project manager (PM) as it has been explained to me is one in which the PM may not have managerial control of project subordinates and must use persuasion and communication to keep the project on track and the team members delivering. The contemporary PMI definitions make the PM responsible for several project guidance and reporting deliverables, and providing these represents actual overhead costs. Although some will say the effort involved in being a PM is not enough to justify it as a full-time role, I would argue that it could be, depending on the project and complexity.
Resource Management
In my past experience with PM work, one of the things I've struggled with is when members of the team are expected to materially participate in the PM duties. If your projects are anything like the ones I've been on, then you're familiar with the corporate American tendency to want things as fast as possible. Especially with software, it shouldn't take long because software is just a bunch of typing and how hard can that be?
But as the blog has noted before, software is only easy if you want to produce garbage. It requires real focus and a mental investment to create effective software, and when the programmers have to also spend time delivering project management deliverables, the programmers are forced to spend less time on analysis, design, construction, and testing efforts. That often leads to frustration for both the developers and the PM.
It is not wrong to expect some developer input in PM deliverables, but certainly this is overhead that needs to be considered lest the staff feel they are once again forced to work unpaid overtime to produce something other than actual product.
PMs versus Developers, Users, and Analysts
The overhead of PM work distributed among the team can at least be managed. There's a more serious disconnect that can happen when it comes to the subject of determining project quality. Scott Ambler's written a little about this in his blog at Dr. Dobbs Journal.
To summarize, Ambler ran a survey that included questions about how project members define IT projects a success. Although the survey sample was modest (Ambler got roughly 600 responses) some of the results alarmed him. He found that:
"It appears that project managers are more interested in delivering on time and on budget than delivering when the system is ready."
He conceded that the sample size didn't include more business stakeholders and so the statistics might need to be taken with a grain of salt, but the general thought does make sense. The goals of the PMI would certainly stress "on time and on budget" as measurable goals. Software quality, on the other hand, is harder to measure. Because of that, it's also hard to estimate the effort needed to reach it in planning phases. The concept of quality is also subjective and that doesn't help matters.
Maybe Software isn't a Project
Here's another idea. Software is a living document. It changes over time and as long as people are using it and maintaining it, it's never done. Does that sound like something you can harness with a beginning, middle, and end?
George Stepanek, the author of Software Project Secrets (Apress ISBN10: 1-59059-550-5), notes that the formal project management methodology is not a good match for software development. Static phases like initiation, planning, and concluding are more a match for traditional waterfall software methodologies than newer "agile" methodologies. Although I'm not as down on waterfall as most are (all waterfall did was win WWII, send a man to the moon, and get the space shuttle into space, among other things), there's no denying that regardless of approach, software is a series of iterative feedback loops between developers and users that extends far beyond a stated project period.
Software Management and Project Management Must Coexist
Neither software nor project management are going away anytime soon. Software has become a part of our everyday lives and project management adds appreciable value in helping to "divide and conquer" the body of work corporations do. But developers and project managers have to continue to understand the disconnects between traditional project approaches and software development and also make strides in measuring software quality. If this does not happen, then the industry will continue to be filled with projects that are only successful on the surface. It will continue to be a place that graces a few with bonuses while leaving behind train wrecks for others to clean up in the late hours.
Saturday, May 24, 2008
A Tale of Two Tenets
I'm at a crucial moment in a developing project. Once again I've been tasked with planning changes to shaky software for a high-profile project with an expected due date that was set before developers were consulted. I am looking at our list of change requests and some are downright scary.
The Best Kind of Programming is Refactoring
On one side I'm trying to use this opportunity to continuously improve the existing code base and would like to apply another refactoring pass to follow-up a previous refactoring.
I consider the refactoring performed last year a success. It consolidated an embedded SQL script that was hard-coded and spread through about five different parts of the application. The refactoring was fairly simple, consolidated the code into one object, and has been working great in production since we installed it. I don't think we've seen even one defect come from it. It allowed us to perform some complicated logic, including recursion, for a later project request in a much more controlled fashion (modifying one object instead of five or more).
But it could still be improved. It consolidated the embedded SQL but didn't move it to the most central place such logic could be: on the server in an Oracle PL/SQL package. If it was on the server, its functionality would be reusable not only by the client software but also by other PL/SQL procedures. With this new project, I'm considering making this refactoring part of the applicable change request, but I'm very conflicted about it.
If it ain't Broke, don't Fix It
In an earlier post I said that writers say "The best kind of writing is re-writing," and that perhaps "the best kind of programming is refactoring." I still feel those are valid statements and that disciplined, regular refactorings are a good thing. However, I'm also under pressures to deliver this project in a timely fashion. So what else is new?
Here's the dilemma. I have to decide how I can effect the required functionality change. Do I add the new code object at the client object level, and have it integrate with the existing recently refactored business object, or do I start it with the logic at the PL/SQL level?
Building the new object's guts at the PL/SQL level seems to make sense and is essentially doing what I did not do with last year's object. But the new object will need to communicate with the existing one, and that means I have to also refactor the existing object. That adds overhead to the project for a benefit whose value to the organization I can't quantify yet. In addition, this refactoring would have a few challenges.
I'm sure PL/SQL can handle the logic demands, but I'm unsure if the way I'm currently performing dataset management in the client will translate cleanly to the PL/SQL. The objects's internal data grids will need to be replaced with cursors or work tables and those perform differently than the client's grids technology. And some of the more complicated functionality in the current object may need to be adjusted for the paradigm shift. So I have concerns that moving the logic to the PL/SQL layer isn't just a rote migration. There will also be a translation effort that introduces some risk.
It now becomes a battle of "The best kind of programming is refactoring" versus "If it ain't broke don't fix it." Of course, that's the whole point of refactoring, as McConnell notes in Code Complete. "Refactoring refers to changes in working code..."
On the other hand, "If it ain't broke, don't fix it," says that you might be better off spending time on other improvements. The old saying has some merit with regard to stability, but it can also be perceived as a philosophy of complacency. Fortunately, I don't think complacency is the problem here since the current object is already the product of a recent refactoring and is performing well.
Conclusion
I don't want to work unnecessary overtime. I did it on the last project and it went on for a year and a half and represented a sizable sacrifice on my part that I'm fairly certain was unmatched by anyone else and certainly not by the compensation. So I will probably keep the code at the client level, but still encapsulated in a business object; this will save us the effort involved in the additional refactoring pass of the existing object. The new business objects will be able to communicate with it and I don't foresee significant performance problems. If we need to, we can attack the logic migration at a later time when such refactorings are not subject to the project's time constraints.
Is that the right decision? You could argue either way, but a few points from McConnell's refactoring checklist bear emphasis here:
The Best Kind of Programming is Refactoring
On one side I'm trying to use this opportunity to continuously improve the existing code base and would like to apply another refactoring pass to follow-up a previous refactoring.
I consider the refactoring performed last year a success. It consolidated an embedded SQL script that was hard-coded and spread through about five different parts of the application. The refactoring was fairly simple, consolidated the code into one object, and has been working great in production since we installed it. I don't think we've seen even one defect come from it. It allowed us to perform some complicated logic, including recursion, for a later project request in a much more controlled fashion (modifying one object instead of five or more).
But it could still be improved. It consolidated the embedded SQL but didn't move it to the most central place such logic could be: on the server in an Oracle PL/SQL package. If it was on the server, its functionality would be reusable not only by the client software but also by other PL/SQL procedures. With this new project, I'm considering making this refactoring part of the applicable change request, but I'm very conflicted about it.
If it ain't Broke, don't Fix It
In an earlier post I said that writers say "The best kind of writing is re-writing," and that perhaps "the best kind of programming is refactoring." I still feel those are valid statements and that disciplined, regular refactorings are a good thing. However, I'm also under pressures to deliver this project in a timely fashion. So what else is new?
Here's the dilemma. I have to decide how I can effect the required functionality change. Do I add the new code object at the client object level, and have it integrate with the existing recently refactored business object, or do I start it with the logic at the PL/SQL level?
Building the new object's guts at the PL/SQL level seems to make sense and is essentially doing what I did not do with last year's object. But the new object will need to communicate with the existing one, and that means I have to also refactor the existing object. That adds overhead to the project for a benefit whose value to the organization I can't quantify yet. In addition, this refactoring would have a few challenges.
I'm sure PL/SQL can handle the logic demands, but I'm unsure if the way I'm currently performing dataset management in the client will translate cleanly to the PL/SQL. The objects's internal data grids will need to be replaced with cursors or work tables and those perform differently than the client's grids technology. And some of the more complicated functionality in the current object may need to be adjusted for the paradigm shift. So I have concerns that moving the logic to the PL/SQL layer isn't just a rote migration. There will also be a translation effort that introduces some risk.
It now becomes a battle of "The best kind of programming is refactoring" versus "If it ain't broke don't fix it." Of course, that's the whole point of refactoring, as McConnell notes in Code Complete. "Refactoring refers to changes in working code..."
On the other hand, "If it ain't broke, don't fix it," says that you might be better off spending time on other improvements. The old saying has some merit with regard to stability, but it can also be perceived as a philosophy of complacency. Fortunately, I don't think complacency is the problem here since the current object is already the product of a recent refactoring and is performing well.
Conclusion
I don't want to work unnecessary overtime. I did it on the last project and it went on for a year and a half and represented a sizable sacrifice on my part that I'm fairly certain was unmatched by anyone else and certainly not by the compensation. So I will probably keep the code at the client level, but still encapsulated in a business object; this will save us the effort involved in the additional refactoring pass of the existing object. The new business objects will be able to communicate with it and I don't foresee significant performance problems. If we need to, we can attack the logic migration at a later time when such refactorings are not subject to the project's time constraints.
Is that the right decision? You could argue either way, but a few points from McConnell's refactoring checklist bear emphasis here:
- Are you keeping each refactoring small? A complete move of the logic would bear a proportionate amount of risk and regression testing, so I think electing to postpone a full refactoring does help. I could certainly still peel off outer bits and at least start the process, leaving the rest still in the client.
- Have you considered the riskiness of the specific refactoring and adjusted your approach accordingly? See above.
- Does the change enhance the program's internal quality rather than degrade it? A bit trickier to answer. I don't think refactoring the entire object would have a significant effect on performance or readability, but does give us more options in future solution designs. As I said above, perhaps not valuable enough to entertain at this time.
The battle between fixing something versus cobbling more crappy code onto a crappy foundation is an endless one for most developers, but especially for that group that has to maintain code for shops that aren't involved in commercial software development. Developers in commercial software shops can afford to be purists; developers subject to corporate sensibilities (or insensibilities) have to reconcile that their leaders are revering time to market over software quality. Many of them don't even understand the concept of software quality, and perhaps they don't need to if their business is not software. But at some point someone does and has to fight the battles I've described here. Whether the guys at the top understand it or not, software quality does affect the company's costs and efficiencies.
Tuesday, May 06, 2008
InformationWeek's IT Salary Survey
InformationWeek and ComputerWorld both run annual salary surveys for IT. InformationWeek's was just published in the 28-Apr-08 issue. I like to read these because they have some interesting things to say, but you have to be careful about treating them as the truth. There was a famous thread a year ago at the JoelOnSoftware.com forums titled "How much do you make?" and it ran for weeks and got cross-linked by lots of sites. It's interesting to see how different it was from the InformationWeek survey.
Statistics
First, you have to be careful about the demographics of the survey. InformationWeek says there are 3.8 million IT workers, but less then 10,000 responded to the survey. Not exactly a confidence-inspiring sample size.
The gist of the InformationWeek survey was that salaries were down a bit, as were bonuses. There were some interesting trends noted, that hiring is actually up in the lower salary ranges for positions like help desk work.
The JoelOnSoftware.com thread was filled with people saying they were making a healthy six figures, but that forum is going to be skewed toward experienced developers rather than a mix of all IT professions from infrastructure roles to management. Interestingly, many of the more well-off programmers at the JoS forums hail from New York banking shops.
Unsettling but Perhaps not Surprising News
Hot on the heels of my training class, the thing I really didn't like to read in the InformationWeek survey was that training continues to be a second-class citizen in the realm of IT benefits. I've said it before, if you don't invest in your people it will come back to haunt you.
But then again, maybe that random sampling of 10 thousand people just had it bad. In ComputerWorld's annual rankings of the top 100 companies to work for, education is still a serious benefit for those employers. Good luck getting into one of those companies if you're not already there though.
We don't have Time to do it Right the First Time and We have even less Time for Training
Why doesn't corporate America want to pay for training? One of my theories says it isn't about cheapness, though that is a factor. I still think it's impatience. It takes a long time to get a person trained and productive in a completely new technology stack. It's not impossible, but it certainly seems slower than signing a contractor on that already has the needed skills.
If what the InformationWeek survey says is a real trend though, then perhaps Nicholas Carr was only half right: it's not just that IT doesn't matter - people don't either. Companies can apply the software as a service model to people too. Just pick up some free agent off the waiver wire and dump him when you're done; no training or benefit expense headaches necessary.
But we have this already don't we, between onshore and offshore contracting? And people as a service doesn't work often. It never works as advertised. How many Oracle or SAP ERP implementations have incurred cost overruns? How many have left people happy? That generic out-of-the-box approach leaves a lot to be desired, doesn't it?
Your best bet is to get good people, train them in your business and also help upkeep their skills. It's like the difference between washing your car yourself versus paying someone else to do it. Will that contractor put as much time into detailing your vehicle as you would? Would he or she know the quirks about not using abrasive polishing agents on your custom chrome wheels? Maybe, but if you did it yourself, you'd go the extra mile and you'd also know what parts of the car to be careful around, like that loose handle or that spot that needs rust protection. There will always be differences between companies and how they operate. Who would understand your business better than people that have a stake in its survival and who support it every day?
Amid these salary survey discussions, something to remember is that paying for good people isn't just a cost; it's the cost of doing business.
Statistics
First, you have to be careful about the demographics of the survey. InformationWeek says there are 3.8 million IT workers, but less then 10,000 responded to the survey. Not exactly a confidence-inspiring sample size.
The gist of the InformationWeek survey was that salaries were down a bit, as were bonuses. There were some interesting trends noted, that hiring is actually up in the lower salary ranges for positions like help desk work.
The JoelOnSoftware.com thread was filled with people saying they were making a healthy six figures, but that forum is going to be skewed toward experienced developers rather than a mix of all IT professions from infrastructure roles to management. Interestingly, many of the more well-off programmers at the JoS forums hail from New York banking shops.
Unsettling but Perhaps not Surprising News
Hot on the heels of my training class, the thing I really didn't like to read in the InformationWeek survey was that training continues to be a second-class citizen in the realm of IT benefits. I've said it before, if you don't invest in your people it will come back to haunt you.
But then again, maybe that random sampling of 10 thousand people just had it bad. In ComputerWorld's annual rankings of the top 100 companies to work for, education is still a serious benefit for those employers. Good luck getting into one of those companies if you're not already there though.
We don't have Time to do it Right the First Time and We have even less Time for Training
Why doesn't corporate America want to pay for training? One of my theories says it isn't about cheapness, though that is a factor. I still think it's impatience. It takes a long time to get a person trained and productive in a completely new technology stack. It's not impossible, but it certainly seems slower than signing a contractor on that already has the needed skills.
If what the InformationWeek survey says is a real trend though, then perhaps Nicholas Carr was only half right: it's not just that IT doesn't matter - people don't either. Companies can apply the software as a service model to people too. Just pick up some free agent off the waiver wire and dump him when you're done; no training or benefit expense headaches necessary.
But we have this already don't we, between onshore and offshore contracting? And people as a service doesn't work often. It never works as advertised. How many Oracle or SAP ERP implementations have incurred cost overruns? How many have left people happy? That generic out-of-the-box approach leaves a lot to be desired, doesn't it?
Your best bet is to get good people, train them in your business and also help upkeep their skills. It's like the difference between washing your car yourself versus paying someone else to do it. Will that contractor put as much time into detailing your vehicle as you would? Would he or she know the quirks about not using abrasive polishing agents on your custom chrome wheels? Maybe, but if you did it yourself, you'd go the extra mile and you'd also know what parts of the car to be careful around, like that loose handle or that spot that needs rust protection. There will always be differences between companies and how they operate. Who would understand your business better than people that have a stake in its survival and who support it every day?
Amid these salary survey discussions, something to remember is that paying for good people isn't just a cost; it's the cost of doing business.
Wednesday, April 30, 2008
Course review: Business Analyst Boot Camp (ASPE Tech)
Training Day
Computerworld's editor, Don Tennant, wrote a couple of interesting editorials last month. In one, he took IT workers to task for not being more active in developing their skills to stay competitive with the global marketplace. Actually, he's done that several times in the last few years. However, he was also good to follow up that editorial with some of the feedback he got, and agreed that companies that are quick to outsource ought to also be fair enough to also assist in-house resources with training. This article dovetailed nicely with some of the things I'd been saying earlier in the blog about companies not investing in internal staff, and how some of this might be due more to impatience than to cost. More on that in a future rant.
Provider
The subject at hand is the Business Analyst Boot Camp offered by ASPE Technology. ASPE sent me a brochure about the class and I was pleased with the breadth of subjects it covered. I was especially pleased with the course materials; more on that in a moment. The company offers courses across the spectrum of software development and project management. I won't go into further details on the offerings, you can visit the web site for a course list and pricing.
ASPE appears to work like most third-party training providers I've seen, meaning that they don't staff a set of full-time employees as instructors that continuously learn and teach a specific product. My impression is that ASPE handles the administrative overhead of developing the course syllabus, selecting the materials, and organizing the marketing and scheduling. The instructors are more like contractors that plug into areas of demand depending on their qualifications, locations, and course demand.
Logistics
Kirtane is a former developer that moved to the business analyst (BA) role and now teaches both project management and BA courses. She still does contract BA work for various clients. She's quite personable and entertaining, but I really appreciated that she was able to speak to both the theory and practice of the materials. She has her Certified Business Analyst Professional (CBAP) qualification. She often quoted from her experiences with both public and private institutions. She also teaches other courses for ASPE.
She communicated well and did a good job of fielding questions. She's comfortable with the course materials. We could occasionally get off track but she kept pretty close to the course guide and schedule. I liked that she did not get into heated debates about classic vs. agile approaches and recommended that students use what works for them.
Course
There was a lot to cover in the four days. Key subjects:
I liked that the first day did a nice job of identifying the responsibilities of a typical BA and Kirtane made sure one of the themes of the course was that BAs are not "order takers." When a party presents an idea for a system ("We'd like a new system that runs on gold-plated portable devices because that would really be cool") she was very clear on the point that a BA's first job is identifying the business needs and goals because the idea may not be salient given business risks and resource limitations.
Another excellent point that I appreciated as a developer was the identification of how a good BA delivering good requirements can save maintenance hassles down the road. This slide from the class says it all.
Another benefit is the course's awareness of the PMI and IIBA. There is information in the course relating the BA work to specific phases of the PMI's project management process.
This is an area where I felt ASPE distinguished itself. All the third-party courses I've taken include a custom course guide that is essentially a collection of the slides used to navigate the course and may include some additional worksheets for the in-course exercises. This is provided in the BA Boot Camp and still works as a useful way for the student to follow along and take notes.
The BA Boot Camp also came with some additional texts for students to take home.
Each of these provided detail and reference for future use. This is especially important because BA Boot Camp covered the gamut of BA work from the project initiation all the way to the delivery of a requirements document. A four day class isn't long enough to delve into all the details, so the inclusion of critically regarded books is a big plus. There are clear links in the course guide back to the external texts. This is very handy for future reference.
Finally, all necessary peripherals were included: binder, worksheets, pens and pencils.
Facility
The Texas Training and Conference Center was great and is well designed for courses. There's an antechamber for each classroom that contains a set of phone cubicles and a serving area. The antechamber and classroom are separated by a door so when it's closed students can make calls and the TXTACC staff can work in the serving area with minimal disturbance to the class. Each class has ample seating space, desk space, and accouterments such as a projector, easels, and whiteboards. The staff is accommodating and responsive. If we ever had technical issues, someone quickly addressed them. Each day the staff kept the serving area stocked with beverages, a continental breakfast, and an afternoon snack.
Summary
I learned much but still had some questions at the end. I definitely gained knowledge of Use Cases, gained a better definition of the BA role, learned several new tools to help illustrate issues and derive requirements, and I have some fine books to continue my education with.
I enjoyed the class and found Kirtane's insights and tips that weren't in the course materials good to have.
Computerworld's editor, Don Tennant, wrote a couple of interesting editorials last month. In one, he took IT workers to task for not being more active in developing their skills to stay competitive with the global marketplace. Actually, he's done that several times in the last few years. However, he was also good to follow up that editorial with some of the feedback he got, and agreed that companies that are quick to outsource ought to also be fair enough to also assist in-house resources with training. This article dovetailed nicely with some of the things I'd been saying earlier in the blog about companies not investing in internal staff, and how some of this might be due more to impatience than to cost. More on that in a future rant.
Provider
The subject at hand is the Business Analyst Boot Camp offered by ASPE Technology. ASPE sent me a brochure about the class and I was pleased with the breadth of subjects it covered. I was especially pleased with the course materials; more on that in a moment. The company offers courses across the spectrum of software development and project management. I won't go into further details on the offerings, you can visit the web site for a course list and pricing.
ASPE appears to work like most third-party training providers I've seen, meaning that they don't staff a set of full-time employees as instructors that continuously learn and teach a specific product. My impression is that ASPE handles the administrative overhead of developing the course syllabus, selecting the materials, and organizing the marketing and scheduling. The instructors are more like contractors that plug into areas of demand depending on their qualifications, locations, and course demand.
Logistics
- The course is four days long, 8:30am to 4:30pm. Due to some of the class leaving early to catch flights we finished in just under four and sped up the last day's subjects.
- My course had ten students and was in a dedicated training facility.
- Students came from various parts of the US and 80% were from the energy industry. Seven were business analysts, one was an IT manager, and two were developers.
- The course is recognized by both the International Institute of Business Analysts (IIBA) and the Project Management Institute (PMI) and is worth 28 development units toward certification in either of those organizations.
Kirtane is a former developer that moved to the business analyst (BA) role and now teaches both project management and BA courses. She still does contract BA work for various clients. She's quite personable and entertaining, but I really appreciated that she was able to speak to both the theory and practice of the materials. She has her Certified Business Analyst Professional (CBAP) qualification. She often quoted from her experiences with both public and private institutions. She also teaches other courses for ASPE.
She communicated well and did a good job of fielding questions. She's comfortable with the course materials. We could occasionally get off track but she kept pretty close to the course guide and schedule. I liked that she did not get into heated debates about classic vs. agile approaches and recommended that students use what works for them.
Course
There was a lot to cover in the four days. Key subjects:
- Foundations of Requirements Development - BA skill set, term definitions
- Project Initiation - Identifying project scope and stakeholders and goals, using a context diagram to identify actors and goals and high-level data flows
- Eliciting Functional and Non-functional Requirements - Using various process analysis tools, interviewing techniques, data definition, taking into account the need to process CRUD functions (Create, Retrieve, Update, Delete)
- Documenting Requirements with Use Cases - Information and exercises on writing and refining Use Cases
- Creating and Presenting the Requirements Specification - Sample formats of requirements documents, some discussion of thorny issues like traceability, discussion of communication
I liked that the first day did a nice job of identifying the responsibilities of a typical BA and Kirtane made sure one of the themes of the course was that BAs are not "order takers." When a party presents an idea for a system ("We'd like a new system that runs on gold-plated portable devices because that would really be cool") she was very clear on the point that a BA's first job is identifying the business needs and goals because the idea may not be salient given business risks and resource limitations.
Another excellent point that I appreciated as a developer was the identification of how a good BA delivering good requirements can save maintenance hassles down the road. This slide from the class says it all.Another benefit is the course's awareness of the PMI and IIBA. There is information in the course relating the BA work to specific phases of the PMI's project management process.
Time is spent also studying the sources of requirements data BAs must work with and how to use techniques and tools to give the requirements shape. Everything from interviewing to using various diagrams. The class discussed ways to disarm reluctant subject matter experts and how to channel the ideas of more enthusiastic ones without without letting them compromise the bounds of their role.
New for me was the work on things like context diagrams and Use Cases. There were several tools presented for identifying requirements; no one tool is the answer and often a combination is needed. I was looking forward to putting together the requirements document, but unfortunately our rushing a bit at the end meant we only reviewed this information. However, I still have the course materials to refer to. The exercises were also helpful in reinforcing ideas and showing that getting requirements isn't any easier for a BA than it is for a developer.
I also liked the course concepts of functional versus non-functional requirements. Strangely, when I went back to the course guide to look up this section there was little to identify it in the section where it is named. We did discuss it in class, but in the guide I had to go to the sample requirements document in the course guide to get some details on what a non-functional requirement is.
I'd done some requirements as a developer before and one of my goals coming into the class was to learn how to use a mixture of graphics and text to more concisely capture requirements detail without creating a huge document and without losing the speed of just typing text. I don't know that I met this goal because we discovered in the class that with requirements you could keep going into more and more details. My experience has been that the more detailed the requirements document can be, the better the information is for the developer. Yet, time constraints often limit the detail, and I'm still trying to reconcile how to be both detailed and agile. The Use Cases may help as they use text in a semi-structured way and with brevity as a goal. But as you expand a Use Case to handle exceptions, it can grow to be as complicated as pseudo-code. Cockburn advises against getting too detailed because the document then becomes unwieldy, a point he doesn't have to make twice to anyone.
This issue of being able to determine the appropriate level of requirement detail is one I struggled with in the class and will continue to work on. However, the context diagrams and activity diagrams and Use Case diagrams may all serve me well in my work.
Traceability, the concept of being able to reference the requirements at a later date and keep them updated for changes, fascinated me. Sadly, this is almost as hard as keeping code updated. There are expensive professional traceability solutions out there, but it appears that with regard to conventional documents the best traceability tool is still a human being.
MaterialsThis is an area where I felt ASPE distinguished itself. All the third-party courses I've taken include a custom course guide that is essentially a collection of the slides used to navigate the course and may include some additional worksheets for the in-course exercises. This is provided in the BA Boot Camp and still works as a useful way for the student to follow along and take notes.
The BA Boot Camp also came with some additional texts for students to take home.
- More About Software Requirements by Karl Weigers
- Writing Effective Use Cases by Alistair Cockburn
- The Software Requirements Memory Jogger by Ellen Gottsdiener
Each of these provided detail and reference for future use. This is especially important because BA Boot Camp covered the gamut of BA work from the project initiation all the way to the delivery of a requirements document. A four day class isn't long enough to delve into all the details, so the inclusion of critically regarded books is a big plus. There are clear links in the course guide back to the external texts. This is very handy for future reference.
Finally, all necessary peripherals were included: binder, worksheets, pens and pencils.
Facility
The Texas Training and Conference Center was great and is well designed for courses. There's an antechamber for each classroom that contains a set of phone cubicles and a serving area. The antechamber and classroom are separated by a door so when it's closed students can make calls and the TXTACC staff can work in the serving area with minimal disturbance to the class. Each class has ample seating space, desk space, and accouterments such as a projector, easels, and whiteboards. The staff is accommodating and responsive. If we ever had technical issues, someone quickly addressed them. Each day the staff kept the serving area stocked with beverages, a continental breakfast, and an afternoon snack.
Summary
I learned much but still had some questions at the end. I definitely gained knowledge of Use Cases, gained a better definition of the BA role, learned several new tools to help illustrate issues and derive requirements, and I have some fine books to continue my education with.
I enjoyed the class and found Kirtane's insights and tips that weren't in the course materials good to have.
Tuesday, April 29, 2008
The Vanguard
Giving Props to the Business Analysts
I am taking a slight change in direction and will be reviewing a recent class I took. I'm fortunate to be working for a company that is willing to invest some funding into developing its people. I attended a Business Analyst Boot Camp offered by ASPE Technology. To preface that, this entry is to pay some respects to the business analyst (BA) world and explain why I feel developers can benefit from learning BA skills.
In the class, I received exposure to several aspects of business analyst work. I've been primarily a developer most of my professional life, but I will give my first employer, EDS, some credit for trying to teach us budding systems engineers BA skills. I've since worked with several companies and many different BAs. BAs are like developers: there are many out there, but only a minorty are outstanding. And when you find a good one, he or she is worth keeping.
At the Starting Blocks
Business analysis is where it all starts when it comes to a software application. It's the tip of the sword and while good work at this stage can be compromised by deficiencies in development, testing, and change management issues, bad work here will almost certainly lead to problems in the overall effort. Only the presence of experienced developers and project managers might be able to still guide such a project to a successful end, and they would do this by willfully partaking of some of the BA duties. In fact, this has happened on many of my past projects and it was when the developer was willing to hash out the business issues and processes rather than make assumptions that downstream pitfalls were avoided.
That leads me to describe my past experience with BAs. Some had decent domain knowledge and were good communicators and had helpful attitudes. Some even had technical skills and that could be a boon. But I've worked with more than my share of people that probably shouldn't have been in IT, much less BAs. I've met a few that simply were non-factors; they didn't participate, they didn't provide timely answers for developer questions, weren't too hot on requirements documentation, didn't get involved in testing or user training, and didn't forge relationships with stakeholders. In effect, if they at least had a helpful attitude, they were glorified secretaries that organized meetings.
That is why I as a developer took this course. The BA skillset includes things like requirements definition, interviewing, conflict resolution, project initiation and elaboration, meeting management, and a whole host of both written and verbal communication skills. All of those things are valuable skills even if you're not formally a BA. A developer, even with the assistance of a good BA, will still have to be able to elicit requirements. There are always going to be missed gaps and unforseen issues, especially on complicated systems. Remember, making software is easy, but making it right is hard. Being able to perform these duties just makes a developer more rounded. In the agile development methodologies, this is even more important because there might not be a BA; the developers and functional owners are co-located and work together in real-time.
Quality is Everybody's Responsibility
Not to belittle a good BA, but most of the BA skills are ones that can be harnessed by anyone that wants to participate in the role (in fairness, I earlier wrote that anyone can become a programmer too). So I took the class because my experience has proven that when a developer is materially involved in the requirements research, it leads to less risk that the software will fail to meet those requirements. This is one of the points that defines software quality.
Some developers would not like this. They would say, "I don't want to document the requirements, I'm a developer." What they really mean is that they'd prefer not to document anything and they would rather just hack away.
For the developers that get outstanding requirements handed to them by either a BA or a developer willing to do BA duties, fine. But at least in the US, conventional wisdom is that code-only developers will become rarer as companies look at offshoring models. And the reality is that most of the time, there isn't a tight requirements document handed over. So, to uphold some measure of quality, good business analysis must be done and it doesn't really matter if it's done by a BA, a project manager, a developer, a functional owner, or a raccoon. If it's done, and done well, it makes a difference. Quality is everybody's responsibility.
In the next entry, I'll write about the class.
I am taking a slight change in direction and will be reviewing a recent class I took. I'm fortunate to be working for a company that is willing to invest some funding into developing its people. I attended a Business Analyst Boot Camp offered by ASPE Technology. To preface that, this entry is to pay some respects to the business analyst (BA) world and explain why I feel developers can benefit from learning BA skills.
In the class, I received exposure to several aspects of business analyst work. I've been primarily a developer most of my professional life, but I will give my first employer, EDS, some credit for trying to teach us budding systems engineers BA skills. I've since worked with several companies and many different BAs. BAs are like developers: there are many out there, but only a minorty are outstanding. And when you find a good one, he or she is worth keeping.
At the Starting Blocks
Business analysis is where it all starts when it comes to a software application. It's the tip of the sword and while good work at this stage can be compromised by deficiencies in development, testing, and change management issues, bad work here will almost certainly lead to problems in the overall effort. Only the presence of experienced developers and project managers might be able to still guide such a project to a successful end, and they would do this by willfully partaking of some of the BA duties. In fact, this has happened on many of my past projects and it was when the developer was willing to hash out the business issues and processes rather than make assumptions that downstream pitfalls were avoided.
That leads me to describe my past experience with BAs. Some had decent domain knowledge and were good communicators and had helpful attitudes. Some even had technical skills and that could be a boon. But I've worked with more than my share of people that probably shouldn't have been in IT, much less BAs. I've met a few that simply were non-factors; they didn't participate, they didn't provide timely answers for developer questions, weren't too hot on requirements documentation, didn't get involved in testing or user training, and didn't forge relationships with stakeholders. In effect, if they at least had a helpful attitude, they were glorified secretaries that organized meetings.
That is why I as a developer took this course. The BA skillset includes things like requirements definition, interviewing, conflict resolution, project initiation and elaboration, meeting management, and a whole host of both written and verbal communication skills. All of those things are valuable skills even if you're not formally a BA. A developer, even with the assistance of a good BA, will still have to be able to elicit requirements. There are always going to be missed gaps and unforseen issues, especially on complicated systems. Remember, making software is easy, but making it right is hard. Being able to perform these duties just makes a developer more rounded. In the agile development methodologies, this is even more important because there might not be a BA; the developers and functional owners are co-located and work together in real-time.
Quality is Everybody's Responsibility
Not to belittle a good BA, but most of the BA skills are ones that can be harnessed by anyone that wants to participate in the role (in fairness, I earlier wrote that anyone can become a programmer too). So I took the class because my experience has proven that when a developer is materially involved in the requirements research, it leads to less risk that the software will fail to meet those requirements. This is one of the points that defines software quality.
Some developers would not like this. They would say, "I don't want to document the requirements, I'm a developer." What they really mean is that they'd prefer not to document anything and they would rather just hack away.
For the developers that get outstanding requirements handed to them by either a BA or a developer willing to do BA duties, fine. But at least in the US, conventional wisdom is that code-only developers will become rarer as companies look at offshoring models. And the reality is that most of the time, there isn't a tight requirements document handed over. So, to uphold some measure of quality, good business analysis must be done and it doesn't really matter if it's done by a BA, a project manager, a developer, a functional owner, or a raccoon. If it's done, and done well, it makes a difference. Quality is everybody's responsibility.
In the next entry, I'll write about the class.
Thursday, March 13, 2008
Code is Shit
Please forgive what appears to be a regression in my language usage. But I'm working with more code written by an expensive contractor and I've just got to say this because bad code is definitely a source of more overtime. It's hard to manage and hard to decipher and suffers higher risk for defects. I'd told this individual several times to try and reduce the complexity of the code and several times this advice fell on deaf ears. This individual is smart, and that's part of the problem. Code that doesn't seem complicated to her is in fact very ugly to the rest of us on the team; not necessarily because the rest of us are stupid but because we will live with this code far longer than the person writing it and well past the point when this person is no longer around.
How can I do a better job of explaining the difference between using introductory versus advanced techniques? Maybe I have to start with changing the attitude about code. Instead of treating code as something beautiful, which it rarely is, perhaps I should start calling it shit. Oh my, a four letter word!
However, there is precedent for my approach. J. van Mannen is a criminologist who has published books on his studies of police work. He has a term he uses to describe any difficult individual law enforcement must deal with: "The Asshole." I'm not kidding, you can look this up. I learned of this when I took a criminology class at UC Irvine taught by James Dombrink.
Just as van Mannen could find no more concise or accurate a term as "the asshole" to describe this element of the population, "shit" is a fine way to describe code. Think about it: would you rather manage a cup of rabbit turds or shovelfuls of horse manure? This also ties in nicely with what expert developers will tell you about the difference between novice and advanced developers. New or thoughtless developers are usually all about hacking away and adding what they can. Increasing the amount of code is considered good programming and even fun. But an experienced developer understands that the best practice is not about adding code but reducing it.
Code is shit. Improving it is not about what you can keep piling on, but about what you can take away.
Subscribe to:
Posts (Atom)