tjt Posted April 8, 2017 Report Posted April 8, 2017 (edited) When you hit your teenage years you decide you want to be a software developer. During your high school years, you learn how to write software using object-oriented principles. When you graduate to college, you apply all the principles you’ve learned to areas such as Artificial Intelligence or 3D graphics. And when you hit the professional circuit, you begin your never-ending quest to write commercial-quality, maintainable, and “perfect” code that will stand the test of time. Commercial-quality. Huh. That’s pretty funny. I consider myself lucky, I *love* design patterns. I like studying the theory of coding perfection. I have no problem starting up an hour-long discussion about why my XP partner’s choice of inheritance hierarchy is wrong — that HAS-A is better than IS-A in so many cases. But something has been bugging me lately and I am wondering something… …is good code impossible in modern software development? The Typical Project Proposal As a full-time contract developer (and part-time), I spend my days (and nights) developing mobile applications for clients. And what I’ve learned over the many years I’ve been doing this is that the demands of client work preclude me from writing the real quality apps that I’d like to be. Before I begin, let me just say it’s not for a lack of trying. I love the topic of clean code. I don’t know anyone who pursues that perfect software design like I do. It’s the execution that I find more elusive, and not for the reason you think. Here, let me tell you a story. Towards the end of last year, a pretty well-known company put out an RFP (Request for Proposol) to have an app built for them. They’re a huge retailer, but for the sake of anonymity let’s call them Gorilla Mart. They say they need to create an iPhone presence and would like an app produced for them by Black Friday. The catch? It’s already November 1st. That leaves just under 4 weeks to create the app. Oh, and at this time Apple is still taking two weeks to approve apps. (Ah, the good old days.) So, wait, this app has to be written in…TWO WEEKS?!?! Yes. We have two weeks to write this app. And unfortunately, we’ve won the bid. (In business, client importance matters.) This is going to happen. “But it’s OK,” Gorilla Mart Executive #1 says. “The app is simple. It just needs to show users a few products from our catalog and let them search for store locations. We already do it on our site. We’ll give you the graphics, too. You can probably — what’s the word — yeah, hardcode it!” Gorilla Mart Executive #2 chimes in, “And we just need a couple coupons the user can show at the cash register. The app will be a throwaway. Let’s get it out the door, and then for Phase II we’ll do something bigger and better from scratch.” And then it’s happening. Despite years of constant reminders that every feature a client asks for will always be more complex to write than it is to explain, you go for it. You really believe that this time, it really can be done in two weeks. Yes. Yes! We can do this! This time it’s different! It’s just a few graphics and a service call to get a store location. XML! No sweat. We can do this…I’m pumped! Let’s go!!! It takes just a day for you and reality to once again make acquaintance. Me: So, can you give me the info I need to call your store location Web Service?The Client: What’s a Web Service?Me: ……….. And that’s exactly how it happened. Their store location service, found right where it’s supposed to be on the top-right corner of their website, is not a web service. It’s generated by Java code. Ixnay with the API-ay. And to boot, it’s hosted by a Gorilla Mart strategic partner. Enter the nefarious “3rd party.” In client terms, a “3rd party” is akin to Angelina Jolie. Despite the promise that you’ll be able to have an enlightening conversation over a nice meal and hopefully hook up afterwards…sorry, it ain’t happenin’. You’re just gonna have to fantasize about it while you take care of business yourself. In my case, the only thing I was able to wrestle out of Gorilla Mart was a current snapshot of their current store listings in an Excel file. I had to write the store location search code from scratch. The double-whammy came later that day — they wanted the product and coupon data online so it could be changed weekly. There goes hardcoding! Two weeks to write an iPhone app have now become two weeks to write an iPhone app, a PHP backend, and integrate them togeth–what? They want me to handle QA, too?? To make up for the extra work, the coding will have to go a little faster. Forget that abstract factory, use a big fat for loop instead of the composite, there’s no time!!!! Good code has become impossible. Two Weeks To Completion Let me tell you, that two weeks was pretty miserable. First, two of the days were eliminated due to all-day meetings for my next project. (That amplifies how short a timeframe this was going to be.) Ultimately, I really had eight days to get things done. The first week I worked 74 hours and the next week…god…I don’t even recall it’s been eradicated from my synapses. Probably a good thing. I spent those eight days writing code in a fury. I used all the tools available to me to get it done: copy-and-paste (AKA re-usable code), magic numbers (avoiding the duplication of defining constants and then, gasp!, retyping them), and absolutely NO unit tests! (Who needs red bars at a time like this, it’d just demotivate me!) It was pretty bad code and I never had time to refactor. Considering the timeframe, however, it was actually pretty stellar, and it was “throwaway” code after all, right? Does any of this sound familiar? Well just wait, it gets better. As I was putting the final touches on the app (the final touches being writing the entirety of the server code), I started to look at the codebase and wondered if maybe it was worth it. The app was done after all. I survived. I SURVI- “Hey, we just hired Bob, and he’s very busy and he couldn’t make the call, but he says we should be requiring users to provide their email addresses to get the coupons. He hasn’t seen the app, but he thinks this would be a great idea! We also want a reporting system to get those emails from the server. One that’s nice and not too expensive. (Wait, that last part was Monty Python.) Speaking of coupons, they need to be able to expire after a number of days we specify. Oh, and…” Let’s step back. What do we know about what good code is? Good code should be extendable. Maintainable. It should lend itself to modification. It should read like prose. Well, this wasn’t good code. Another thing. If you want to be a better developer, you must always keep this inevitably in mind: The client will always extend the deadline. They will always want more features. They will always want change — LATE. And here’s the formula for what to expect: (# of Executives)2 + 2 * # of New Executives + Bob’s Kids = DAYS ADDED AT LAST MINUTE Now, Executives are decent people. I think. They provide for their family (assuming Satan has approved of their having one.) They want the app to succeed (promotion time!). The problem is that they all want a direct claim to the project’s success. When all is said and done, they all want to point at some feature or design decision they can each call their very own. So, back to the story, we added a couple more days to the project and got the email feature done. And then I collapsed from exhaustion. The Clients Never Care As Much As You Do The clients, despite their protestations, despite their apparent urgency, never care as much as you do about the app being on time. The afternoon that I dubbed the app completed, I sent an email with the final build to all the stakeholders, Executives (hiss!), managers and so on. “IT IS DONE! I BRING YOU V1.0!!! PRAISE THY NAME.” I hit Send, lay back in my chair and with a smug grin began to fantasize how the company would run me up onto their shoulders and lead a procession down 42nd street while I was crowned “Greatest Developer Ev-ar.” At the very least, my face would be on all their advertising, right? Funny, they didn’t seem to agree. In fact, I wasn’t sure what they thought. I heard nothing. Not a peep. Turns out the folks at Gorilla Mart were eager to and had already moved on to the next thing. You think I lie? Check this out. I pushed to the Apple Store without filling in an app description. I had requested one from Gorilla Mart and they hadn’t gotten back to me and there was no time to wait. (See previous paragraph.) I wrote them again. And again. I got some of our own management on it. Twice I heard back and twice I was told, “What did you need again?” I NEED THE APP DESCRIPTION! One week later, Apple started testing the app. This is usually a time of joyousness but it was instead a time for mortal dread. As expected, later in the day the app was rejected. It was about the saddest, poorest excuse to allow a rejection I can imagine: “App is missing an app description.” Functionally perfect; no app description. And for this reason Gorilla Mart didn’t have their app ready for Black Friday. I was pretty upset. I’d sacrificed my family for a 2-week super sprint, and no one at Gorilla Mart could be bothered to create an app description given a week of time. They gave it to us an hour after the rejection — apparently that was the signal to get down to business. If I was upset before, I would become livid a week and a half after that. You see, they still hadn’t gotten us real data. The products and coupons on the server were fake. Imaginary. The coupon code was 1234567890. You know, phoney baloney. (Balogna is spelled baloney when used in that context, BTW.) And it was that fateful morning, I checked the Portal and THE APP WAS AVAILABLE! Fake data and all! I cried out in abject horror and called up whoever I could and screamed, “I NEED THE DATA!!!!” and the woman on the other end asked me if I needed fire or police and so I hung up on 911. But then I called Gorilla Mart and was like, “I NEED DATA!!!!” and I’ll never forget the response: Oh, hey there John. We have a new VP and we’ve decided not to release. Pull it off the App Store, would you? In the end, it turned out that at least 11 people registered their email addresses in the database, which meant there were 11 people that could potentially walk into a Gorilla Mart with a fake iPhone coupon in tow. Boy, that might get ugly. When it was all said and done, the client had said one thing correctly all along: the code was a throwaway. The only problem is it was never released in the first place. Rush To Complete, Slow To Market The lesson here is that your stakeholders, whether an external client or internal management, have figured out how to get developers to write code quickly. Effectively? No. Quickly? Yes. Here’s how it works: Tell the developer the app is simple. This serves to pressure the development team into a false frame of mind. It also gets the developers to start working earlier, whereby they… Add features by faulting the team for not recognizing their necessity. In this case, the hardcoded content was going to require app updates to change. How could I not realize that? I did, but I’d been handed a false promise earlier, that’s why. Or a client will hire “a new guy” who’s recognized there is some obvious omission. One day a client will say they just hired Steve Jobs and can we add alchemy to the app? Then they’ll… Push the deadline. Over and over. Developers work their fastest and hardest (and BTW are at their most error-prone, but who cares about that, right?) with a couple days to go on a deadline. Why tell them you can push the date out further while they’re being so productive? Take advantage of it! And so it goes, a few days are added, a week is added, just when you had worked a 20-hour shift to get everything just right. It’s like a donkey and carrot, except you’re not treated as well as the donkey. It’s a brilliant playbook. Can you blame them for thinking it works? But they don’t see the god-awful code. And so it happens time and again despite the results. Code Impossible In a globalized economy, where corporations are held to the almighty dollar and raising the stock price involves layoffs, overworked staffs, and offshoring, this strategy I’ve shown you of cutting developer costs is making good code obsolete. As developers, we’re going to be asked told conned into writing twice the code in half the time if we’re not careful. Source: http://raptureinvenice.com/is-good-code-impossible/ Edited April 8, 2017 by tjt 1 Quote
