What Kind of Learning Developer are You?
Getting to a place where a person calls himself a developer is just part of the story. The other half is really about how he develops himself once he's in his career.
Ultimately, it depends on the kind of person the developer is. I've seen a couple scenarios in my experience:
The Renaissance Man
You know the character that is always the nemesis of the everyman hero in romantic comedies?He's the guy that looks like he's going to get the girl the hero wants because he's a double PhD in law and medicine, inherited more money than you'll find in the Denver mint, plays guitar, can charm cats, is an award-winning chef in his spare time, owns stocks that only go up in value, and looks like he walked off the cover of some glossy magazine. Oh yeah, he also knows every language O'Reilly has ever published a book on and can work at a high level of mastery.
Yeah, that guy. Not many exist, thank God, but these guys aren't just lucky, they're also deeply talented. They are the Mozart to your Salieri, and you can't do anything about it. Programming is well served by people capable of blending outstanding memories with quick minds, an ability to manage complex concepts, and organizational skills. Most of us have some of those things but not all of them. What does that mean? It means the Renaissance guy can study less and learn more because it comes naturally. So for him education doesn't require quite the investment of time it does everyone else. It also doesn't hurt that these guys make the effort to learn and can apply what they learn in their craft and their lives. That's what makes them Renaissance guys; learning isn't some uphill battle they do to try to get ahead, it's just a part of who they are. And it isn't just programming crap. These guys seem to learn everything.
Management advice: Don't worry about these guys, they'll take care of themselves. They're probably already making more money from their side businesses than what you pay them.
The Nerd
Nerds are en rapt by the whole world of software and computers. Unlike the Renaissance Man, for whom learning is natural, the Nerd has to work at it. The Nerd tells himself he enjoys it, but that's just a defense mechanism to deal with the fact that again unlike the Renaissance Man, the Nerd is socially estranged and isn't doing much else on Saturday nights. Learning about new techniques and technologies is above rejection on the entertainment scale. Fortunate Nerds work for companies that pay for the cost of education. But most are like the other 80% of the world's tech workers, where IT is considered a cost center, and they'll have to learn on their own resources. But either way the drive to learn is self initiated and they seek knowledge of their own volition.
Management advice: Nerds make great employees if you can handle their eccentricities. They won't make a jump to sales anytime soon, but they'll do good work and they're reliable. Do what you can to support their interests in learning. It'll boost their morale and benefit the organization.
The Resume Builder
This developer's strength is that she is always looking forward and cognizant of industry trends. The weakness is a desire to always be at that cutting edge and a fear that working on the old stuff is death in the marketplace. While there is some validity to that fear, I'm still seeing systems that run on COBOL, so its death, for those that are proficient in the language and willing to work with it, has been highly exaggerated. The same could be said for FoxPro, pre-.Net Visual Basic, PowerBuilder, and C++.
The Resume Builder is always learning, but unlike the Nerd and the Renaissance Man, the Resume Builder never develops deep proficiency. The Resume Builder, currently using language X, will be satisfied with a year or less of experience with it, and even at the day job, will be stealing time from work to study language Y. When an opportunity to use language Y appears, at the same company or elsewhere, the Resume Builder will move on. Once entrenched in her new position, the Resume Builder will begin studying hot new language Z, and will be ready to move on again in a year.
The Resume Builder's resume is indeed impressive, with every programming language conceivable on it. But what the resume doesn't tell you is that the code the Resume Builder wrote wasn't very high quality. It might have been Visual Basic, or PL/SQL, or Java, or C#, but it tended to solve problems the same way in each language, rather than using the language's strengths. It would include T-SQL that used lots of cursors instead of set theory or it might be an OO language where the methods were each 500+ lines of spaghetti code instead of smaller, logically partitioned components. The resume also doesn't mention that the Resume Builder, busy moving between languages, tends to repeat the same mistakes in each new language.
Finally, the resume also doesn't tell the story of the Resume Builder's poor motivation while working with language X. Any assignments in language X were done quickly and with a band-aid approach. Sometimes a band-aid approach is the correct tactical response when the preferences of a developer and a project manager clash but everyone wants to stay employed. The actions of the Resume Builder aren't of that type; they don't leave behind a rushed solution with useful documentation for those who must follow; they leave behind a train wreck caused by neglect for maintenance.
Perhaps I shouldn't be so hard on the Resume Builders. At least their learning is still self motivated, even if the motivation is for the next job and not necessarily for building quality solutions. Frankly, the Resume Builders probably don't care what I think. They're too busy counting their money.
Management advice: Nope. I know you wouldn't listen to me anyway because you keep hiring these guys.
The Anchor
Sometimes developers don't care to learn. It's not that they won't or that they don't enjoy it. They might even like it, but they're not motivated to do it regularly on their own. This is because learning involves substantive effort outside of work. And that's an important distinction I haven't mentioned: learning job-related skills on the job versus learning them as an extracurricular activity.
The Renaissance Man learns with ease anytime, anywhere. The Nerd has to work on it but typically doesn't have a problem committing personal time. The Resume Builder might also do it at work and at home, but prefers to bootleg time from work (and I don't mean bootleg in the nice 3M way, where bootlegging led to the creation of the now ubiquitous Post-It Note). The Anchor will plod along at work, primarily doing work, and when the bell rings at 5pm, he's only doing work at home if it's for a production emergency. The Anchors will learn if someone is forcibly hauling them through the water or holding their hands through a software learning exercise. But it had better be on company time. Left to their own devices outside of work, they'll opt to do something else they find more palatable.
There's nothing wrong with the Anchor's philosophy. It's rather laudable in a work-life balance approach. However, learning isn't really about work even if it's about work-related skills. It's about self development and furthering one's ability as a developer. If someone is too busy at work to learn new things that help both himself and his employer, they'll both be endlessly mired in the same approaches with the same problems. Any improvements from this camp will be rare and of incremental value. Having lots of these guys means that instead of building a staff of Renaissance Man wannabes, you'll have a staff of guys that do as little as possible. They'll never sufficiently refactor the software so that they can spend more time furthering the company's strategic goals and less time fighting fires in overtime (see, I worked the overtime angle into the post after all).
Management advice: Anchors aren't going to lead the way in evolutionary improvements for the organization. They can be reliable in some roles, but be careful about putting them in positions where they are going to make decisions for software projects of considerable risk and complexity.
Keeping it Real
Despite some grains of truth, the above was a largely humorous look at different learning motivations for developers. The truth is that you can't cleanly and completely categorize any person. I myself could have fit into any of those categories (except for that Renaissance thing) at different times in my career depending on my level of maturation, experience, and the environment.
That's enough about intrinsic motivation. Next time, I've got some thoughts on how developers learn.
Saturday, September 08, 2007
Friday, May 25, 2007
The Difference a Year Makes
I've done the very thing a blogger isn't supposed to do. I went nearly a year before posting. What happened?
IT and Happiness
A job change can always be a time sink. I made a decision last year to trade a little money for some intangibles. I've been busy as blazes trying to wrench a big project into order. Was the change worth it? I think so; as I tell my friends, you're not supposed to be able to buy happiness. But I sort of did that, not by buying it direcly but by giving up purchasing power in trade (a fancy way of saying I took a pay cut to make the move).
A theme I was supposed to pontificate on last year was what happiness means in IT. What a pretentious bastard to assume I could know such a thing, huh? I'll take a stab at it anyway, because if nothing else, writing is cheap therapy.
On that note, and given my recent experience, let's talk about money. Everyone needs it even if they don't love it. And you know what? I think everyone loves it even if they say they don't. Not everyone loves it equally, but it means a lot in a world where things tend to get more expensive, not less. But it's an important part of any worker's life, so here's the truth about it from my perspective.
How Much is Enough?
That's what employees and employers want to know, right?
Employers, you don't have to be a top compensator, but do keep abreast of the salary surveys and make sure you're not too far out of the loop. Seriously. And be willing to boost your long time loyal veterans if they're not up to the market standard, or they'll leave and do it themselves. If they're not smart enough to keep up with what's going on, do you even want them working for you?
Employees, keep an eye on those salary surveys but keep a decent perspective on reality too. Are you really delivering the quality a 15 year senior person is supposed to be delivering? Are you being honest in your assessment of yourself? In the end of course, your network may have more to do with your career success than your ability. How much is enough? That's ultimately up to each individual, but I believe most are reasonably happy if they are enough above breaking even to live comfortably. They're even happier if they can get far enough above that to have a savings account and live with some minor luxuries. For most developers, that's a good spot to be in. Money above that point is gravy, but isn't worth having if you have to give up having a decent supervisor, good working conditions, and challenging work that engages you.
The Intangibles
When you get older, you realize that money is important, especially in a society where it is the main bartering tool. But there are indeed things money cannot buy that developers do appreciate:
IT and Happiness
A job change can always be a time sink. I made a decision last year to trade a little money for some intangibles. I've been busy as blazes trying to wrench a big project into order. Was the change worth it? I think so; as I tell my friends, you're not supposed to be able to buy happiness. But I sort of did that, not by buying it direcly but by giving up purchasing power in trade (a fancy way of saying I took a pay cut to make the move).
A theme I was supposed to pontificate on last year was what happiness means in IT. What a pretentious bastard to assume I could know such a thing, huh? I'll take a stab at it anyway, because if nothing else, writing is cheap therapy.
On that note, and given my recent experience, let's talk about money. Everyone needs it even if they don't love it. And you know what? I think everyone loves it even if they say they don't. Not everyone loves it equally, but it means a lot in a world where things tend to get more expensive, not less. But it's an important part of any worker's life, so here's the truth about it from my perspective.
How Much is Enough?
That's what employees and employers want to know, right?
Employers, you don't have to be a top compensator, but do keep abreast of the salary surveys and make sure you're not too far out of the loop. Seriously. And be willing to boost your long time loyal veterans if they're not up to the market standard, or they'll leave and do it themselves. If they're not smart enough to keep up with what's going on, do you even want them working for you?
Employees, keep an eye on those salary surveys but keep a decent perspective on reality too. Are you really delivering the quality a 15 year senior person is supposed to be delivering? Are you being honest in your assessment of yourself? In the end of course, your network may have more to do with your career success than your ability. How much is enough? That's ultimately up to each individual, but I believe most are reasonably happy if they are enough above breaking even to live comfortably. They're even happier if they can get far enough above that to have a savings account and live with some minor luxuries. For most developers, that's a good spot to be in. Money above that point is gravy, but isn't worth having if you have to give up having a decent supervisor, good working conditions, and challenging work that engages you.
The Intangibles
When you get older, you realize that money is important, especially in a society where it is the main bartering tool. But there are indeed things money cannot buy that developers do appreciate:
- Decent work environment
- Quality peers
- Decent tools
- Access to training
- Book budget
- Flexible hours
- Mangement that understands quality is not always free, swift, or easy
- A work environment with minimal interruptions
- Career path (including a non-management path)
- Management that values its full-time employees more than contractors (and pays for it with more than lip service)
- Decent equipment (reasonably current PC and dual monitors)
- Management that says Yes as often as it says No
- Opportunities to work with advanced or new technology in productive and meaningful ways
Monday, May 29, 2006
A Job to Do
Memorial Day (Observed) - May 29, 2006
I'm going to take a quick break and just say a 'Thank you to our veterans.
I continue to be impressed with members of The Greatest Generation. Whenever I talk to them at airshows or special events, they are always humble about the role they played in WWII. In particular, they avoid being pretentious about their achievements and are modest about them. What a contrast from the younger generations. The WWII vets defeat Germany and Japan and, after one well-earned homecoming party nicknamed the Baby Boom, go quietly about their regular jobs. The younger generations watch their favorite professional sports team win a championship on TV and then spend the next year spouting trash talk.
But there's something that just sums up the WWII generation so well. It's a phrase I've heard several of them say, almost as if they'd collectively rehearsed that this would be their response to questions about their hardships.
When visiting the USS Hornet museum in San Francisco, the veteran leading our tour spoke of the working conditions in the bowels of the aircraft carrier. Temperatures in the engine rooms could reach above 100 Fahrenheit but still the young sailors maintained their posts. "We had a job to do," was all he said in response to our amazement.
At another function I chatted with bomber crews. The bombers, despite their size and defensive armaments, where easy pickings for enemy fighters. Many were lost. Still the crews manned their stations and kept flying. "We had a job to do."
-----
Here at The Burning Ends, my inspiration comes largely from spending time in the often inoptimal working conditions of most corporate American IT shops. I named the blog after the concept of harsh overtime but none of what modern workers deal with compares to the challenges met by our veterans. Those guys on the aircraft carriers worked 12-hour shifts every day, and here I am whining about having to pull a 50-hour week.
I am justified too, because my complaints aren't directed at the the concept of overtime itself, which I often give anyway when I'm happily engrossed in a project. They're directed at inadequate or unethical leadership. And that's something worth bitching about. On that note, what a satisfying verdict the Enron trial gave us a few days ago. Now several of the rotten leaders of the 1990's boom are formally criminals. This latest news reminds that humanity isn't a lost cause, no matter how hard we try to prove otherwise. Perhaps we have not wasted the efforts of our veterans.
Each generation has plenty of problems, usually more than it can solve. But as long as humans keep pushing out a few solutions too, then we have a chance to stay in that perpetual uphill battle.
Tonight, I'll raise a glass to the veterans, and to a job well done.
I'm going to take a quick break and just say a 'Thank you to our veterans.
I continue to be impressed with members of The Greatest Generation. Whenever I talk to them at airshows or special events, they are always humble about the role they played in WWII. In particular, they avoid being pretentious about their achievements and are modest about them. What a contrast from the younger generations. The WWII vets defeat Germany and Japan and, after one well-earned homecoming party nicknamed the Baby Boom, go quietly about their regular jobs. The younger generations watch their favorite professional sports team win a championship on TV and then spend the next year spouting trash talk.
But there's something that just sums up the WWII generation so well. It's a phrase I've heard several of them say, almost as if they'd collectively rehearsed that this would be their response to questions about their hardships.
"We had a job to do."
When visiting the USS Hornet museum in San Francisco, the veteran leading our tour spoke of the working conditions in the bowels of the aircraft carrier. Temperatures in the engine rooms could reach above 100 Fahrenheit but still the young sailors maintained their posts. "We had a job to do," was all he said in response to our amazement.
At another function I chatted with bomber crews. The bombers, despite their size and defensive armaments, where easy pickings for enemy fighters. Many were lost. Still the crews manned their stations and kept flying. "We had a job to do."
-----
Here at The Burning Ends, my inspiration comes largely from spending time in the often inoptimal working conditions of most corporate American IT shops. I named the blog after the concept of harsh overtime but none of what modern workers deal with compares to the challenges met by our veterans. Those guys on the aircraft carriers worked 12-hour shifts every day, and here I am whining about having to pull a 50-hour week.
I am justified too, because my complaints aren't directed at the the concept of overtime itself, which I often give anyway when I'm happily engrossed in a project. They're directed at inadequate or unethical leadership. And that's something worth bitching about. On that note, what a satisfying verdict the Enron trial gave us a few days ago. Now several of the rotten leaders of the 1990's boom are formally criminals. This latest news reminds that humanity isn't a lost cause, no matter how hard we try to prove otherwise. Perhaps we have not wasted the efforts of our veterans.
Each generation has plenty of problems, usually more than it can solve. But as long as humans keep pushing out a few solutions too, then we have a chance to stay in that perpetual uphill battle.
Tonight, I'll raise a glass to the veterans, and to a job well done.
Saturday, May 13, 2006
The Five Things Developers Forget about in Heaven
Yes, this entry's title is a riff on Mitch Albom's book The Five People You Meet in Heaven. Largely inspired by the previous blog entry, here's a post about things typical developers ignore because they're either inexperienced, lazy, or plain stupid.
These are the kinds of things that many developers don't want to think about; they just want to do the 'fun' part, the quick hacking together of a GUI and some half-baked business rules. But that's like only doing the fun part of making a baby. Failing to uphold responsibilities as a parent and partner can yield a very imbalanced child. People wanting to only do the fun parts should get out of enterprise IT and become developers only after they get to the big workstation in the sky (I couldn't write 'cubicle in the sky' because I'm not sure there are cubicles in heaven).
And no, no one person is perfect and has the time to be a complete expert in all the below items. But someone on the project team better be thinking about these, and preferably at design time so they don't become emergency projects later in a system's life. If making software right is hard, making it right after it's already in production is harder. The alternative? Get ready to burn that candle at both ends.
Archiving
If a system is going to last a while, it's going to collect data. Queries, I/O operations, and general system performance all get slower as a system has to hash through more data. But an archiving approach for older data always seems to be an afterthought to most application developers. This is also becoming more important in an age of legal compliance (read: Sarbanes Oxley).
Concurrency and Scalability
Thanks to years like 1999, the developer ranks are filled with Visual Basic* and Excel* macro people that think applications have only one user. So they don't design to protect against dirty reads and writes. What's sad is that RDBMSs and some programming language tools have support for managing concurrency and protecting data, but these features are either ignored or worse, coded around!
* Note that I'm not necessarily against Excel or VB, both of which can be outstanding tools, but more the mentality of people that spend a few months with them and then, with no exposure to advanced computing issues, assume they can work on enterprise systems (and at fat contract rates!).
Data Modeling
This is arguably the most important item on the list. A database structure that satisfies the business needs and is technically sound is paramount to a system's business value, agility, performance, and maintainability. Too many developers think programming is all about building a GUI. But a cruddy GUI on a solid database can always be replaced. It is more difficult and expensive to repair a broken database foundation under a beautiful GUI.
As an adjunct point, SQL, and cousins like PL/SQL and T-SQL, are not to be scoffed at and seen as nuisances. They are tools like any other and when used properly can simplify the work of the client and middle tiers. They are valuable allies in addressing the challenge of application partitioning and code reuse.
Documentation
All companies suffer turnover. Sometimes it's because the company stinks. Sometimes it's because the company is fine but the market is good and someone just gets a great opportunity. Sometimes people decide for a career change or want to have kids. In the end, someone other than the original developer(s) will have to look at the code. For the love of God, document. Document in design papers. Document in code comments. Document in technical papers and user manuals. Others will benefit from it and so will you.
Yes, it's possible to document too much (see Scott Ambler's articles on agile documentation). Overbearing loads of documentation can put people to sleep and can themselves become a maintenance hassle to keep current. But a lack of documentation or the presence of poor documentation are much more common concerns.
Security
It's the age of the Internet, viruses, email fraud, wireless networks, and cheap multiple-gigabyte portable storage. But no matter what age it is, there are always humans around. Humans are evil. It's better to plan for protection at design time rather than a year after going live.
These are the kinds of things that many developers don't want to think about; they just want to do the 'fun' part, the quick hacking together of a GUI and some half-baked business rules. But that's like only doing the fun part of making a baby. Failing to uphold responsibilities as a parent and partner can yield a very imbalanced child. People wanting to only do the fun parts should get out of enterprise IT and become developers only after they get to the big workstation in the sky (I couldn't write 'cubicle in the sky' because I'm not sure there are cubicles in heaven).
And no, no one person is perfect and has the time to be a complete expert in all the below items. But someone on the project team better be thinking about these, and preferably at design time so they don't become emergency projects later in a system's life. If making software right is hard, making it right after it's already in production is harder. The alternative? Get ready to burn that candle at both ends.
Archiving
If a system is going to last a while, it's going to collect data. Queries, I/O operations, and general system performance all get slower as a system has to hash through more data. But an archiving approach for older data always seems to be an afterthought to most application developers. This is also becoming more important in an age of legal compliance (read: Sarbanes Oxley).
Concurrency and Scalability
Thanks to years like 1999, the developer ranks are filled with Visual Basic* and Excel* macro people that think applications have only one user. So they don't design to protect against dirty reads and writes. What's sad is that RDBMSs and some programming language tools have support for managing concurrency and protecting data, but these features are either ignored or worse, coded around!
* Note that I'm not necessarily against Excel or VB, both of which can be outstanding tools, but more the mentality of people that spend a few months with them and then, with no exposure to advanced computing issues, assume they can work on enterprise systems (and at fat contract rates!).
Data Modeling
This is arguably the most important item on the list. A database structure that satisfies the business needs and is technically sound is paramount to a system's business value, agility, performance, and maintainability. Too many developers think programming is all about building a GUI. But a cruddy GUI on a solid database can always be replaced. It is more difficult and expensive to repair a broken database foundation under a beautiful GUI.
As an adjunct point, SQL, and cousins like PL/SQL and T-SQL, are not to be scoffed at and seen as nuisances. They are tools like any other and when used properly can simplify the work of the client and middle tiers. They are valuable allies in addressing the challenge of application partitioning and code reuse.
Documentation
All companies suffer turnover. Sometimes it's because the company stinks. Sometimes it's because the company is fine but the market is good and someone just gets a great opportunity. Sometimes people decide for a career change or want to have kids. In the end, someone other than the original developer(s) will have to look at the code. For the love of God, document. Document in design papers. Document in code comments. Document in technical papers and user manuals. Others will benefit from it and so will you.
Yes, it's possible to document too much (see Scott Ambler's articles on agile documentation). Overbearing loads of documentation can put people to sleep and can themselves become a maintenance hassle to keep current. But a lack of documentation or the presence of poor documentation are much more common concerns.
Security
It's the age of the Internet, viruses, email fraud, wireless networks, and cheap multiple-gigabyte portable storage. But no matter what age it is, there are always humans around. Humans are evil. It's better to plan for protection at design time rather than a year after going live.
How do these guys find jobs?
I'm working right now on something that should be fairly simple in most applications: adding two columns of data to a screen. I have to update the logic that retrieves and saves the data, and also modify the GUI to accept user input and display the new columns.
The Horror
But this task is taking me two or three times the normal amount of time because the original developer didn't understand the programming tool's strengths and probably wasn't too hot on data modeling either. In exploring the table that stores this data, I found that the table has no primary key and nary an index. There's no relational integrity established through keys or triggers, and columns used to define uniqueness at a row level can have mutating values if the user wants to change the data. *Shudder*
Moreover, in the GUI the original developer didn't cater to the strengths of the programming language's construct for managing data (it's the PowerBuilder datawindow, one of the best object-relational mapping devices out there, I don't care what anyone else thinks). The constuct makes database interactions very easy if you work with it rather than against it. The original developer instead bypasses the tool and puts responsibility for updates and deletes for key columns in list box controls outside of the datawindow, manually controlling everything. This is like clubbing yourself in the knees with a sledgehammer.
He loads the list boxes with the possible values for the columns. You pick what you want and save it to the database. But when scrolling through the datawindow, he is also reloading the list box values whenever a different row gets focus, and then populating the list boxes with the values in the current row, so that as you navigate rows, the list boxes mirror the values. He could have simply kept all this in the main datawindow, because the user can already see what the values are there, but that would have been too easy.
And of course, the coup de grace is that for everything (the updates, the loads of the list box values, and deletes), instead of simply configuring the datawindow correctly and issuing a single PowerBuilder update() command, this fellow offloads everything to embedded SQL, which is a mistake in several ways. It spreads data access across several points increasing the complexity of coupling. It also creates a context switch from programming language to SQL, which can cause performance problems in some languages. It gets worse; you know the part where he is keeping the list box values in sync with the current datawindow row? He is triggering a full repopulation of the list box values with each row change, and the list boxes are populated with embedded SQL cursors, a totally needless construct in the PowerBuilder world. This means that even though you have everything you need in the main datawindow, this app is generating several SQL calls to the database with every click on a different row. This creates both network traffic and database server loads that are completely unnecessary.
Sepukku
This means that instead of having to make small modifications to the table, a stored procedure, and the GUI screen, I have to create new list boxes, plus tons of new code to manage them within the same "framework" the original developer created. What should have been about half a day of work becomes almost two days given the extra work and testing that needs to be done.
Why didn't I just rebuild the whole thing? This is where the Ghost of Project Manager Past is supposed to come in and take the blame, but it doesn't happen and even if it did, the truth remains: I am on a deadline to get this work done, and it will be actually less expensive to do it inefficiently than to fix it and make it right. I groan with every line I write, despising myself for it, but I get it done and sneak in an improvement or two. If I was the Ghost of Project Manager Present, I would change the project scope and maybe rebuild the app. But Boss of Project Manager Present would probably not approve.
Lesson Learned?
How do guys like the original developer get hired in the first place? And why aren't they held accountable for their work? Please see my earlier entry, Mind Your Contractors.
The Horror
But this task is taking me two or three times the normal amount of time because the original developer didn't understand the programming tool's strengths and probably wasn't too hot on data modeling either. In exploring the table that stores this data, I found that the table has no primary key and nary an index. There's no relational integrity established through keys or triggers, and columns used to define uniqueness at a row level can have mutating values if the user wants to change the data. *Shudder*
Moreover, in the GUI the original developer didn't cater to the strengths of the programming language's construct for managing data (it's the PowerBuilder datawindow, one of the best object-relational mapping devices out there, I don't care what anyone else thinks). The constuct makes database interactions very easy if you work with it rather than against it. The original developer instead bypasses the tool and puts responsibility for updates and deletes for key columns in list box controls outside of the datawindow, manually controlling everything. This is like clubbing yourself in the knees with a sledgehammer.
He loads the list boxes with the possible values for the columns. You pick what you want and save it to the database. But when scrolling through the datawindow, he is also reloading the list box values whenever a different row gets focus, and then populating the list boxes with the values in the current row, so that as you navigate rows, the list boxes mirror the values. He could have simply kept all this in the main datawindow, because the user can already see what the values are there, but that would have been too easy.
And of course, the coup de grace is that for everything (the updates, the loads of the list box values, and deletes), instead of simply configuring the datawindow correctly and issuing a single PowerBuilder update() command, this fellow offloads everything to embedded SQL, which is a mistake in several ways. It spreads data access across several points increasing the complexity of coupling. It also creates a context switch from programming language to SQL, which can cause performance problems in some languages. It gets worse; you know the part where he is keeping the list box values in sync with the current datawindow row? He is triggering a full repopulation of the list box values with each row change, and the list boxes are populated with embedded SQL cursors, a totally needless construct in the PowerBuilder world. This means that even though you have everything you need in the main datawindow, this app is generating several SQL calls to the database with every click on a different row. This creates both network traffic and database server loads that are completely unnecessary.
Sepukku
This means that instead of having to make small modifications to the table, a stored procedure, and the GUI screen, I have to create new list boxes, plus tons of new code to manage them within the same "framework" the original developer created. What should have been about half a day of work becomes almost two days given the extra work and testing that needs to be done.
Why didn't I just rebuild the whole thing? This is where the Ghost of Project Manager Past is supposed to come in and take the blame, but it doesn't happen and even if it did, the truth remains: I am on a deadline to get this work done, and it will be actually less expensive to do it inefficiently than to fix it and make it right. I groan with every line I write, despising myself for it, but I get it done and sneak in an improvement or two. If I was the Ghost of Project Manager Present, I would change the project scope and maybe rebuild the app. But Boss of Project Manager Present would probably not approve.
Lesson Learned?
How do guys like the original developer get hired in the first place? And why aren't they held accountable for their work? Please see my earlier entry, Mind Your Contractors.
Saturday, April 29, 2006
Time for Song
Hacking and methodologies and pointy-haired-manager busting and SQL and language wars and best practices and requirements gathering and testing and bugs and dealing with spaghetti code and arbitrary deadlines and corporate America and viruses and still trying to fit time in for family and gaming and reading. Whew.
Take a break and enjoy a song from eccentric folk singer Johnathan Coulton. This one's called Code Monkey and it's hilarious. That it works on several levels (poking fun at programmers and their struggles with management, social ineptness, and dreams of success) might be genius, or it might be serendipity.
Either way, the song is catchy and this page includes a link to the song, Coulton's song notes, and feedback from several listeners. Elsewhere on his site you can also find the lyrics. The only thing I would have changed is the song's reference to "Tab and Mountain Dew." In my universe, it would be "Code Red Mountain Dew."
Take a break and enjoy a song from eccentric folk singer Johnathan Coulton. This one's called Code Monkey and it's hilarious. That it works on several levels (poking fun at programmers and their struggles with management, social ineptness, and dreams of success) might be genius, or it might be serendipity.
Either way, the song is catchy and this page includes a link to the song, Coulton's song notes, and feedback from several listeners. Elsewhere on his site you can also find the lyrics. The only thing I would have changed is the song's reference to "Tab and Mountain Dew." In my universe, it would be "Code Red Mountain Dew."
Monday, April 10, 2006
Define Happiness
If someone came to you and asked, "Are you happy with your IT job," how would you respond?
Obviously, the person asking would have an impact. You might answer differently if a friend asked than you would if a manager asked.
At the risk of sounding Clintonesque, I think you also have to clarify the question first, by saying, "Define happiness."
If you spend time reading the mentally engaging discussions at Joel Spolsky's site Joel on Software, you might get the impression that the ace developers out there all want jobs where there's no overtime and a working environment void of interruptions. Both of those are good things to have, and both are the sorts of things the evolved software development experts talk about (guys like DeMarco and Lister).
The truth is that it's considerably more complicated than that. There are varying types of developers and varying types of IT jobs. So, as is often the case, before we can answer the original question, we have to answer several other questions.
I'll be exploring this before returning to the happiness question.
Obviously, the person asking would have an impact. You might answer differently if a friend asked than you would if a manager asked.
At the risk of sounding Clintonesque, I think you also have to clarify the question first, by saying, "Define happiness."
If you spend time reading the mentally engaging discussions at Joel Spolsky's site Joel on Software, you might get the impression that the ace developers out there all want jobs where there's no overtime and a working environment void of interruptions. Both of those are good things to have, and both are the sorts of things the evolved software development experts talk about (guys like DeMarco and Lister).
The truth is that it's considerably more complicated than that. There are varying types of developers and varying types of IT jobs. So, as is often the case, before we can answer the original question, we have to answer several other questions.
I'll be exploring this before returning to the happiness question.
Subscribe to:
Posts (Atom)