At my current project there's some pretty significant involvement from the business in the details and minutia of the application design. For better or for worse, each and every business user wants to know exactly how things are going to work, and wants to put their two cents into the design. It's a lot of cooks in the kitchen, and as a developer it's easy to complain about that... But I should really make the best of it. After all, it could be worse.
I'm reminded of a previous job at a bank that no longer exists. (I've said it before and I'll say it again... A bank going bankrupt is irony at its best, and it also an astounding example of a business running itself into the ground.) At one point during my brief tenure there I was tasked with fixing a bug in an application owned by the HR department. It was a basic one-off HR utility, grabbing data from here and there and moving some bits around so they can do something. No big deal. But it suddenly stopped working recently. And it stopped working in a weird way.
Normally it would iterate through every employee in the company, connect each one to some other data in some manner relevant to HR, and update some data in a transactional database owned by the application (and, thus, by the HR department). Then it would email some reports to key individuals based on the new state of the data.
Note that I keep pointing to the fact that this is owned by the HR department. That's a significant part of the point I'm trying to make.
The "weird way" in which it "stopped working" was that it would run as scheduled, update some data, and send some reports. But it didn't update everything. It took a little cajoling with the HR point of contact (which I think was also head of HR... we'll call her the Product Owner) to get more relevant information (she's used to being protective of this data... but I'm not interested in the real-world values of the strings and integers, just the fact that there are strings and integers), but the pattern which was eventually uncovered was that it only "worked" for employees whose surnames began with A-F (semi-inclusive), and never for any employees whose surnames were F+ (semi-inclusive).
The pattern indicates pretty clearly what, or at least where, the problem lies. Something is wrong with the data for an employee whose surname begins with F, and the application is silently failing. And this data is relatively new, as the system only recently stopped working. (Though, in hindsight, "recently" in bank-time could have been two years while the department awaited approval and navigated the sea of red tape to get a bug fixed.)
So I set about debugging. The arduous process of stepping through somebody else's code and examining values. And let me assure you that this code was a mess. I was told that it was written by somebody who didn't really know .NET very well, and was accustomed to developing in another system. I take statements like that with a grain of salt, understand. And I do this because the errors weren't necessarily .NET-specific errors. If the developer didn't use LINQ or didn't use built-in functionality to perform common tasks, that's one thing. But we're talking about serious logical problems. Looping through data in unimaginably inefficient ways in order to find a value that you already have in another data structure, things like that.
But I digress...
I tracked down the problem, and wrote a detailed analysis of it. This was earlier in my career, and while I don't have the analysis anymore I am confident that it could have been worded much more professionally. So I approach this particular anecdote with a modicum of understanding of the events as they unfolded. Nevertheless, I sent this analysis to my supervisor and to the Product Owner.
The analysis essentially laid out the logic surrounding the error, indicating specifically where and why the error occurred, the logical nature of the error (the application was assuming that every entity in Active Directory was an employee, and that every "employee" email address was unique... the falseness of the former assumption led to the falseness of the latter assumption), etc.
I was proud of this analysis. I'd not only found the nature of the problem, but I'd found a prime candidate of code that needed to be re-factored and cleaned, which would result in an application that's easier to maintain and dramatically more efficient for the users. So the analysis was also a request for clarification. What should the logic be? Clearly, the logic as it stands right now is inaccurate. But without any further knowledge of what the application should be doing (again, the code didn't give much indication of this), I needed collaboration with the Product Owner.
"She doesn't know or care about these details; It's your job to fix it."
Those weren't my supervisor's exact words, I don't think, but that's essentially the gist of it. And the other people in my group agreed. More vehemently than respectfully (again, earlier in my career), I disagreed.
How can the Product Owner not know or not care about the business logic driving her application? Sure, the implementation details are unimportant to her. That's where the developer's "magic" comes into play. But the logic? That is most certainly owned by the Product Owner. I can't tell her what her application is supposed to do. I can suggest logic to achieve the desired business outcome, but that logic needs her collaboration. She can't just expect to toss some vague concept over a wall and expect somebody to toss back a completed application.
Can she?
"That's just how we do things here." If you've read my previous posts, you've seen that one. It's the same place.
Again, I completely and wholly disagree. At its core, the application was "broken" because it logically defined the unique identifier for an employee as an email address. Does HR use this to uniquely identify an employee? If so, then I agree that there's a technical implementation detail which broke that logic. Nonetheless, it's useful information for the Product Owner. Apparently enterprise-wide that particular unique identifier isn't as reliable as originally assumed, and something in the business logic may need to be adjusted. But then... If that's not how HR uniquely identifies an employee, then the application isn't expressing the business rules of the HR department. The Product Owner definitely needs to know about that. And, for lack of additional information, the Product Owner needs to work with the developer to correct the logic so that it accurately and completely reflects the business rules.
Either way, the Product Owner needs to be involved. But... She doesn't care about such details? At another previous job I once said, "If the people who want this software don't care about it, why should I?" It's kind of passive-aggressive, but the point remains. It's either important or it isn't. It's either worth your attention or it isn't.
If your software isn't worth your attention, expect bad software. And don't be surprised when you get it. (Loosely translated: Don't come crying to me when you get everything you want. I'll help you fix it, but I won't take accountability for the parts that weren't under my control.)
Ok, I'm slipping back into passive-aggressive mode. I do apologize for that. It's something I need to correct. But, again, I digress...
My point is that everybody needs to care about the software. Everybody who's involved, anyway. The developer, the tech lead, the project manager, the tester, the product owner, the data analyst, the executives who run the whole company... everybody. Anybody who doesn't care about the project doesn't belong on the team.
Wait... the executives?
Yes, the executives. Everybody who has a stake in the software. This particular example of a stakeholder highlights a particular scenario, though. Not everybody has the time to personally be involved in the software. This doesn't mean they shouldn't care, it simply means that they delegate the responsibility to somebody else and trust that somebody. And that somebody needs to deliver. They need to care.
So, maybe the Product Owner in this case didn't have the time to personally be involved. Then delegate. And trust your delegation. That means that if you delegate your ownership of the software entirely to the developer, then understand that whatever the developer does is owned by you. The developer is responsible for his or her decisions, naturally. But as the person who delegated the effort, so are you.
The previous developer made the wrong decisions. Don't make the same mistake again.
Your software is as important as you make it. If you just do some hand-waving and walk away, what results do you expect?
So, for better or for worse, at least my current client cares. The business person does need to know. And the business person wants to know. Which is a pretty good position to have.
No comments:
Post a Comment