Is Good Code Impossible?
This blog seems to have sparked a little bit of backlash towards me as if I were an irresponsible developer making things worse on my peers. I assure you, it’s not true. Sometimes, in business, we have to be willing to accept a little more work than we’d like or a little more hardship in general to gain something back. What was gained from the client was (A) good notoriety for having worked with them and (B) the promise of a longer and more lucrative Phase II. In all things, there is give and take. We gave as much as took.
—
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.
What can we do about it? Check out Is Good Code Impossible Part 2: Project Manipulation Patterns next.
John Blanco
John Blanco is a freelance iOS developer living in Lakewood, Colorado. He's been developing mobile apps for over 15 years, beginning in the medieval days of Java ME and Blackberry and all the way through iPhone and Android! He's led development on dozens of apps across a wide variety of domains such as retail, vision, orthotics, games, sports, and more!
Follow Me:
The Three20 Framework: Should You Use It? Are We Really Mobile Developers Anymore?
Comments are currently closed.
76 thoughts on “Is Good Code Impossible?”John Blanco
I've been writing mobile apps professionally for 10 years: Blackberry, Java, ME, iPhone, Android. I've gotten dozens of apps into the various App Stores for dozens of clients, big and small.
My current specialty is in iOS and Xamarin development. If you need an app written at a fixed price or just need a hourly developer to give a boost to your current team, I might be your guy.
Let's make an app!
[…] This post was mentioned on Twitter by G A, Proggit Articles. Proggit Articles said: Is Good Code Impossible?: submitted by ZaBlanc [link] [1 comment] http://trim.li/nk/32rI […]
They are business people and don’t care how good the code is or the design. They just want the product. And, they will try to get as much as possible as few requirements as possble. For the whole part, you were still in the requirements phase. Until you nail down the specifications (dot the final i’s and cross the final t’s) should you start coding. Another way of saying it is that you need a contract. Hash out the contract first before committing to such a project. Even if it means using hand drawings to get your idea across.
Although things never got THAT out of hand for me, I know this story has to be true (and it’s quite funny in a way). As a freelancer you always see clients like this. I learned to ignore all their BS. It’s hard to do it since we, the coders, are so optimistic all the time. The way I go is to just try and make a thorough analysis and estimation, then multiply that by 3 and here you go! (Maybe multiply by 2 if you’re paid by the hour since you don’t care much if it takes longer.) If they need reliability then they found the right coder. If they’re looking for cheap then you managed to avoid a shitty client and save a lot of neural connections in that beautiful brain of yours.
And you’re right: there’s no easy project, no “90% done by other coder”, no real deadline. It’s not even a very smart way to get you to do your best. It’s just cheap managerial BS they heard somewhere and they try it because, well, why not? Maybe it works. And anyway what’s a manager gonna do all day anyway? You’re busy coding; they’re busy figuring out how to make you be cheaper (and miserable). You’re just a tool anyway and you’re doing your job like they’re doing theirs.
That’s the “wannabe manager”. But don’t get me wrong: I’ve seen very good managers. Managers so good I’d always love working with them. The thing is those managers are the best at what they do and used to code a while back and understand what coding means. Unfortunately there are so many wannabe managers it’s getting more and more difficult to find the great ones.
And I guess like managers so are coders. There are great coders you always love coding with, or discussing ideas, brainstorming whatever, because you know you’ll end up with a great idea together, and a great experience. Definitely better outcome than any one of you alone could come to. And there are the zillions of wannabe coders who… well… I wish they never ever existed in my universe. You know those who manage to make your day miserable. Perhaps starting with those who work hard when the boss is around but never actually do anything. They usually have cunning plans for their next amazing app that will never see the light but they always talk about it like it’s almost ready to ship. Or those who beg everybody to help them fix a bug and then write to all managers and CC all company employees taking credit for fixing the nobody-cares-about-obscure-bug. And if you manage other coders you must have had the experience of asking (a couple of times in a row) for an estimation on a little feature so you know if it’s worth coding it or not and the answer is “How should I know? We’ll see when I finish coding it”. How about the “I don’t want to hear about deadlines today ’cause I don’t feel like coding and my cat is sick” behavior. Seen it all more than one time. I guess I’ve been living between the wrong kind of people and I really got tired of trying to educate people (clients) into making a rough idea of what coding involves or making them (coders) understand what coding means. I’ve seen great coders and great managers and they deserve each other. Then I’ve seen bad coders and wannabe managers and I think they deserve each other too, so no discrimination ;).
And so I’d end up in a place where there’s a common interface between me and the client (which sometimes means I’m being employed). Like maybe the client is a coder, or there’s a BS person talking to the BS person on the other side so I only hear the relevant bits. It also helps if there’s a team of coders as the morale seems to stay higher and tasks can be passed around so not one person feels too much pressure.
And finally at some point family becomes more important and the job goes down to position 10 or 20 on your daily activities priority list (after eating, sleeping, having fun, staying healthy and fit, spending time together with family and friends, travelling etc). And then there’s no more rush and no more stress. It just all vanishes in the shadow of irrelevance. It turns out that’s where things start to be normal.
It’s just a possible way to do it (and very subjective too). I’m sure there are much better ways, but I don’t think it makes much of a difference which way you go as long as you’re happy with who you are and what you do.
Mihai
You’re lucky to have learned programming in high school… although I did web development, it wasn’t until college that I had any formal education in object oriented design. I only got to computer vision by the time I was a senior and working on my thesis!
I actually taught it in high school. I guess I’m sufficiently old enough that when I was in high school, majoring in electronics (it was a trade school), I helped teach the classic BASIC programming. I also learned from it, but overall when I say learning how to code in high school, I technically mean WHILE in high school. The high school years.
you’re lucky to have learned programming in college! When I started there was no such thing as PCs
I had never even seena computer and I was given a manual to “learn to program a PDP-11) that’s
how I learned programming, no computer, no training. I had a call in 2000 asking me if a program I wrote in 1978 was millenium compliant! You know what, it was. Kids today are spoilt, and compiling is
too easy, when you had to type in a program on a teletype (no monitor) and you had to compete
with the operator for time in which to type in your program, you spent days reading the code and
bench-testing it. Nowadays most programmers idea of testing is getting it to compile, and that’s the
trouble.
Reading an article about perfection, I couldn’t help but notice: “They’re is a huge retailer,”
Clearly it was a tight deadline on a simple article =)
Yes, alas, the web abounds with a lack of editing. If coders are expendable, it also seems that editors have already been expended. Something of a pity if, besides coding, you enjoy English.
Despite a few grammatical, spelling, and syntactical glitches, the article was amusing and accessible, however, and it is nice that it saw the light of day. That, too, may be attributed to the absence of an editor.
Good code doesn’t harvest email addresses.
Was this comment written on a computer or a stone tablet?
Great post, but you may want to do some proofreading. Looking forward to part 2.
There is a way to prevent the worst parts of this situation with a little client management. You need to have a document you both sign agreeing what the app will do. You don’t give a time or cost estimate until that document is finalized. All of the back and forth bullshit and scope expansion happens while you’re finalizing the document. Let them know that adding anything later falls outside of the agreement and will also mean less efficient code, so they should get everything they want in that document.
Then, when they inevitably ask for more things while you’re developing, you point to the document and say “that’s out of scope, but here’s my estimate on how long it will take me to add it.” Then they can decide if they really want you to add it after all. (half the time they won’t when they see the relationship their dumb ideas have to actual cost – you can even manage them a little more by padding your estimate for something you really don’t want to do, or shaving off some hours for something you think would be fun to code)
You might think no client would go for this, but the thing is “out of scope” is just the kind of business buzzword people can comprehend. It helps them understand the relationship between their ideas and production time. I do it, and it doesn’t always fix everything, but it’s a huge help.
Really true :(
Awesome Robot is totally and utterly right. Especially around padding the hell out of an estimate on something you know is going to be a real nightmare to get working or integrate into what’s already been done.
Starting work without a list of requirements is a false economy – it just means things are going to spiral out of control during the development process and you’ll end up doing those 80+ hour weeks until they finally pull the project.
I, like many i’m sure, have learned this the hard way and have no intention of making that mistake again. A day or two spent scoping/speccing a job is worth many more at the other end of the project.
I agree in general. Keep in mind this was a bit of a different beast. The client wasn’t mine directly and they were significantly significant enough you just can’t turn it down, especially given that the Phase II would follow — which it did.
Sometimes, you can’t avoid taking tough jobs. Ironically, I started my own iPhone consulting by taking an underbid app. I knew I’d lose on the deal, but Catch-22 dictates I start somewhere. ;-)
Really good article.
But you can fight back against this kind behavior.
1 – Fight the “it is really urgent”:
Perfect, I will need _BEFORE BEING ABLE TO CODE_:
Server providing me the XML format of blablablah…
The description of the app
The complete iPhone page design
etc…
Then even if you begin to code, the manager has to provide you with all that, and if it takes too long, “Sorry, I need more time/cash”
2 – Fight the demand of a new feature:
I am sorry you believed it was simple. In fact, this simple feature change _everything_.
I need 3 weeks of work only for that, and also a team of 10 full time developer.
Believe me, it’s my job, using the “UR a n00b” technic works really well.
3 – Unfortunately I never found a way to fight back the “push the deadline” effect. But I’ve done one thing that can help.
Before the project you state: “We can make things nice if I work 5 weeks, for two weeks, any further change will make me change the _complete_ application.” What do you prefer.
Most of time, they will prefer the crappier but cheaper coding. If they demand another feature after the deadline was pushed. You can use this “email” and say. I’d tell you. If you want to add an icon it is a 2 more weeks works.
Now for the article, It is really true it is almost not possible to create _good_ code in such environment. At work, each time I asked the question : “good and maintainable code vs crappier&cheaper”, the second choice was always chosen. The good part, is now, any slightest change is paid for weeks. Of course, this is a _job_ not enjoyable at all, but you get paid for this.
I’m waiting for the part 2.
hahhaahhahah i know exactly how you feel :D:D:D ! if it is ant kind of consolation you are not alone in fighting Executives :D:D:D
[…] the whole story Categories: Uncategorized Comments (0) Trackbacks (0) Leave a comment […]
moron for letting your work having more priority than you/your family ..
Lucky for having a family so understanding that they support him in his endeavors. We should all be so fortunate.
Work **never** has priority over my family. Occasionally, I just have to do a lot of work. As I get paid hourly, it benefits my family as well.
[…] This post was Twitted by wimverhoef […]
This is a failure of project management on your part. +1 for yogsototh above.
Sales + Marketing > Project Management … I’ll outline how to fight some of this stuff in Part 2. Tough world out there.
Everything Awesome Robot said and more.
Bottom line – it’s 100% your fault.
Uncle Bob ( Robert Martin ) would say your not being a professional, and I agree. I believe your behavior does yourself and the software industry a huge disservice. Because of developers like yourself, many clients believe they can continue to get away with behavior like this.
Stop it now. You are hurting us all.
Read Martin’s ‘Saying “NO”‘, and start working like a professional.
http://blog.objectmentor.com/articles/2009/12/04/saying-no
I’m an Uncle Bob disciple, actually. If having a project progress this way is bad, many of us would be out of work. Real world circumstances sometimes dictate over development ideals. This isn’t how all projects go, but there are certainly some common themes.
Alan, are you sure you work in development? Some of us have to work in the real world, and not the lecture circuit like Uncle Bob.
I think every experienced developer has come across this situation (although maybe not to this extreme). I have learned over the years to be very communicative about how changes to scope will affect budgets and timelines. I’ve found that usually if you’re up-front about these things and present the options and trade-offs, clients understand the situation more and do not make as many unreasonable demands. I’m curious if in this situation you had presented them with such options and trade-offs — if so, did they just brush it off and say “we don’t care, just get it done”, or were there other details of the political situation that made this impossible?
Thanks for the excellent article!
-Jordan Lev
I think you have a problem, that has nothing to do with coding. Whining doesn’t solve anything.
You need to learn to say: NO! Seems simple,but is hard to do.
You look yourself on the mirror each morning and say : “NO”, not a simple “no”, but an assertive, masculine, secure “NO”(No way in hell I’m going to to that). I know what you are thinking, you can’t say no to a client, but that is totally BS. Yes you can. If you let yourself to be abused, you will. If you put it clear that not…you will earn RESPECT, or you are going to loose an abusive customer(better).
I mean you say no in a polite manner and explain it to them why something can’t be done in this period of time. If they try to change conditions,being you the only one that loose , make it clear that then the agreement is over.
I know it sounds strange, like the wild west films in witch the Indians say they are going to kill the westerns and one of them face the Indian boss and as a result he becomes friend of them. Courage is good, and if you apply it you will discover: Only the strong (the good coder) has no fear of losing a job, so if you are courageous it means to them that you are good in their subconscious mind, like letting yourself down means you are desperate to get the job (so you are a bad coder in their mind).
Find the best customers and only work with them, let the bad ones to your competitors. If you are good you can. Life is good when you know how to live.
Bye
Great article. My only thought is that you are in the wrong part of the software development industry if you care about the quality and maintainability of your code.
The only executives and product managers that will care as much as you do and that understand the long-term business value of good code are those that were at least journeymen code craftsmen at one point in their career.
From the blog post, you’ve shown that you can ship a working product in a short amount of time. Go work in or found a startup where you can have a say in balancing a short-term need to ship with the long-term needs satisfied by quality maintainable code.
When you work in a startup, you get to pick your “client” in the sense that your non-technical co-founders are analogous to your client as a freelancer. Only work with those that “get it” when it comes to software development and building technical products.
Agreed. Rapture In Venice is that venture. :-) I agree!
[…] Rapture In Venice » Is Good Code Impossible? (tags: code development) […]
If you didn’t charge enough in those two weeks to not work the rest of the year (think of it as a reverse vacation), you’re doing it wrong. There’s so much demand in this business that you should never be giving up your health or family.
You need a union that sets limits on work hours, or a professional organization that forces companies and clients to adhere to a certain standard, or you need to write better contracts and refuse crappy clients like that.
The client wasn’t refused due to other reasons which I agree with. Business is weighed based on more than just development. In this case, the importance of the client, future work that the company needs, and the ability to gain more business with it are worth a sort of inconvenient project. Keep in mind I got paid hourly, and the decision was mine to set forth.
The goal of the article was to talk about some classic “strategies” used by clients (sometimes purposefully and sometimes not) that can throw kinks in a project. They were a pretty flexible client and I liked working with them, but it was a tough, tough go of it.
In Part 2 I’ll talk about how to avoid these situations, and if you read some of the comments you already hear some basic ideas. :-) (I’ve been linked on Reddit and the comments there are not as nice.) haha
Great post and great debate.
This is a a great story and a great allegory for how the real world trumps principle when it comes to coding. I rarely have the opportunity to code things the way I want to. The reality is that very few people are lucky enough to write software that will be around long enough for it to matter. A good software developer isn’t just one who knows how to write high-quality code- it’s one who knows which corners he can cut to deliver quality, secure products in the time available.
To the people who say “learn to say no,” I have to wonder, where do you work? Who is willing to pay for perfect code all the time? This is a competitive industry. Nobody but you cares what’s under the hood. They just care if it works and is done on time (and maybe even on budget). Most software is disposable. Scalability, maintainability, and performance are not very important for projects with a short lifecycle, and on the off chance it gets traction and stays around, you’ll have the chance to catch up on your long list of TODOs down the road.
Actually, a mechanic once had this sign on the showroom floor:
1) Cheap
2) Fast
3) Done Right
You can have any two you want; but, not all 3.
I like it – otherwise known as…the project management pyramid :)
This sort of thing happens.
I’m familiar with the “OMG Rush, it has to be completed in a week” which then turns into months of client trying to add more features after the “deadline” – without adding budget, and without any inclination to launch.
Sadly I fell for it the first time and it took years off my life. It will not happen again, I’ll just walk.
Life’s too short, I’m off to have fun before I die.
^ Note – the above may be why I am so broke.
Need to find clients who would rather hear a good reason “no” than a weak “ok”.
Good code can’t be achieved with good coders alone, you also need good project management :)
i think the problem is that you are expecting something that is not supposed to be there. a throwaway iphone app does not need to be maintainable or scalable, it needs to serve its function and be forgotten. those things matter when developing real software or websites, things that will cost more to fix if done poorly than to do right the first time around.
Well, if you accept taking the job, then that’s that. No one’s forcing you to do so. You have this fantasy that happiness can be caused by other people. You gotta take some self-responsibility and write your own apps if you want to do the code you want.
Aaaah, agile development.
If you can’t take the heat then get out of the kitchen.
Saying NO is a good thing, it’s not hard to do at all – it’s a simple matter of reasonable and truthful discourse between client and coder.
But the worst possible thing to do is to BS the client by saying a simple feature is going to make you change the entire App. If your code is such that you can’t modify it without re-writing the entire thing, then out the door you go.
You know… this kind of story is happening all to often and it is killing the software industry…
Companies think writing software is as easy as making chocolate milk… mind you the cow has to raised, then has to be milked. The milk then has to be pasturized, homogenized, cartoned, then shipped to the store, where I have actually GO to the store, buy it and bring it home and open it. THEN there is the whole chocolate production… which I am not going to go into… but you get my point… NOTHING is simple in this world, however a lot of things have been made to look simple even though they are not, and software engineering is one of those things “they” (meaning companies and ignorant managers) are trying to pass off as “simple as making chocolate milk” – where in my opinion it will NEVER be.
Software is pure “thought stuff”, more maliable than silver, gold or platinum… and more costly than all three put together… What is sad is that “they” are constantely trying to make it less than that… by saying “it’s simple”… “this is a small app”… there is NO such thing and it is OUR responsibility to advise and educate these unknowing individuals of the complexities of the software world AND to stand FIRM on our estimates… UNLESS you like working 80 hours a week for “simple apps”…
Lawyers and doctors don’t do this…why should we ? I mean would want to have your doctor working on you on a “simple” operation when they worked 80 hours that week and you were the last patient before he clocked out for his weekend… NOT ME !!
WAKE UP and smell the coffee everybody… WE are dooming ourselves !
Since you talked about TDD and refactoring, you must have read about agility and XP.
When applied properly, agility can save you from this mess :
– create a list that clarifies what has to be done (typically a backlog)
also, define what are the interfaces of your software
– in the backlog, the customer gives priorities and you give the estimation of cost
– make short planning sessions for short iterations, with the customer
the planning session is over when you both agree to do what is doable in one iteration at a time
– involve your customer (in planning and releases, in making customer tests)
– use feedback from your customer, in the disciplined way of the backlog (definition, priority, estimation)
– use the customer tests for continuous integration
– deliver at the end of every iteration
Whatever is the dream of the customer, it’s never relevant, it’s only a dream
If the planning matches the customer expectations, he will be happy.
Otherwise, the customer will know very early and will adjust.
At any date, the delivered software is what the iterations allowed you to produce.
Always be honest about what can be done, don’t take your customer for an idiot
It is of no use to talk about TDD or refactoring or whatever if you don’t use it
Don’t talk about it, just use it.
Don’t ask for permission.
In the case of your project, everyone would have gained from this method
– the customer would have learned to drive a project
– you would have gained professionalism and respect (from others and from yourself)
– the software could be used (no need to throw away a prototype)
– the customer and you both would appreciate to work together again
>the demands of client work preclude me from writing real quality apps.
Sorry, that is nothing more than an excuse (and a poor one at that) for writing poor code.
Your illustration demonstrates something that you need to learn. BEFORE you submit your bid, you need to ask the questions that YOU asked AFTER you got the contract. You made a leap of faith (full well knowing you shouldn’t have, I might add) and _assumed_ that you had the full requirements and specifications. (I am sure that I don’t have to explain to you how the word “assume” divides up, do I?)
Your eagerness to get contracts is making you desparate and causing you to ignore all the warning signs and rules for doing the work properly. Is it any wonder that you are whining about being “forced” to write bad code?
Did you have a _written_ contract? Was it _signed_ by anyone who might possibly have the authority to authorize the activity (besides yourself)?
Sorry, very little sympathy from this quarter.
[quote]This blog seems to have sparked a little bit of backlash towards me as if I were an irresponsible developer making things worse on my peers. I assure you, it’s not true. Sometimes, in business, we have to be willing to accept a little more work than we’d like or a little more hardship in general to gain something back. What was gained from the client was (A) good notoriety for having worked with them and (B) the promise of a longer and more lucrative Phase II. In all things, there is give and take. We gave as much as took.[/quote]
I agree with the people saying that you’re an irresponsible developer making things worse for your peers. You are. Think about what you did. You first took a contract that would be very difficult to finish based on time and what they wanted, making assumptions about what they would/could provide that turned out to be false, much to your detriment. These are things you should have found out about before agreeing to the contract, assumptions are always bad. After that, you took on additional changes beyond the original scope of the project, that only made things worse for you. In the end, the client could care less about the app and canceled it. They knew it was as low quality as you did, so completely expendable and worthless.
The client has learned a few things about your shop (and your peers): 1) If I promise future work, they’ll do anything. 2) If I push them hard enough, they’ll do whatever I say. 3) I can change requirements at anytime with no effect on the schedule.
What you gained from the client is not the A and B that you mention, what you gained was: A) a notoriety of being a “yes” development shop that will say “how high?” when they tell you to jump. As such, you are likely expendable (once you get that reputation, what do you think they’ll do if you question something?) B) the promise of future work that is EXACTLY LIKE YOU JUST WENT THROUGH. You’ve conditioned them to expect that you can continue this way.
By saying “yes” to that contract, all you’re doing is perpetuating that type of work. If you don’t like that kind of work, and you know that kind of work is bad for our industry, DON’T DO THAT KIND OF WORK!
Had you said no do their insane demands, you may have lost the client, maybe not, but do you really want a client that has demands like that? The shop that I work for has said “no” to these types of demands for longer than I’ve worked for them – and you know what, we don’t get demands like that anymore. Our clients know that we’re a high-quality shop that does high-quality work so they only come to us with the longer term Phase II type of projects, where high-quality is a requirement. Our client list includes those that we’ve said “no” to before – once they know the difference between a “yes” shop and a high-quality shop, they come to us for the good work.
Do yourself and our industry a favor. Stop taking on this kind of work. If enough development shops stop it, people will stop thinking they can do that.
Bravo Darrell!! I like you (and your company’s) style!
I believe with this particular client is that they didn’t have a handle on their own environment. They promised things they couldn’t deliver, and I had to adjust. In a quick turnaround, I didn’t have the benefit of getting to know their bounds.
As always, there are things I can learn from this. But it’d be unfair to say anyone would have realized what was to happen. I will continue to do my best to polish the process, and I’m happy where things are at.
Darrell makes some excellent points. You have an entertaining story we can all relate to. But really, your own actions helped perpetuate this fiasco.
But most importantly, shouldn’t it be “Bologna is spelled baloney when used in that context…” (not ‘Balogna’)?
Instead of worrying about your ridiculous concepts of “good code” (seriously, wtf is an abstract factory, good grief…) why don’t you learn the amazing concept of saying “NO” to the client, the amazing concept of charging high rates per hour (so you know, even if they cancel the project, you get paid), and spend some thought on how to filter out clients in the future so you don’t have to deal with such nonsense! Stand up for yourself man!!
This wasn’t a prive contract, so it wasn’t a choice. But I was excited to do it. The goal of the article is to outline the problems that occur at runtime, not compile-time. :-)
No one said it’s easy being a developer. Hopefully articles like this help us gain a little more insight on how to make our lives easier. Hopefully you’ll check out Part 2!
Same my story :)
But m sure you will get back to “good code”….it is too tempting not to ;)
I’m addicted. What can I say? :-)
[…] Rapture In Venice » Is Good Code Impossible? […]
On game development, unrealistic schedules and pressure to ship is called a death march. It seem that you had passed one.
My advice:
Put everything in writing and do not diverge from the deal. What is expected from you and what you need to do your job. Anything that goes outside of scope needs and amendment to the original deal. And I mean anything.
Managers are trained to manipulate you so that they can get away as much as they can while giving you as little as possible. This in turns makes them more valuable for the company as the purpose of the company is to make money for the company. But if you get things in writing, including that any change will mean a change in schedule and in billing, they will not break the agreement. They will try to psychologically manipulate you, but you just specify the clause on the contract and stick with it.
Finally, do not rely a 100% of your income on one client. That gives them too much leverage, and they are trained to abuse it as much as they can.
Instead create sources of passive income. (investments, creating applications to be sold, etc.). The less you rely on one person (or organization) as your source of income, the less leverage they have on you at the time of negotiation. Might sound like spending time you don’t have, but in the long run it will give you more time, as you will be never again need to accept a death-march.
i think all seasoned devs have been there…
Yes my friend, like you many developers face the same problem day after day, unfortunately we do not have control over the time being given to build up an entire system, well I liked very much your post and how you put things, it was funny sometimes, others sad but I totally agree with your point of view.
[…] document.getElementById("fb-root").appendChild(e); }()); "Is Good Code Possible?" John Blanco asks on his blog. He goes on to tell a harrowing story on how he had to develop […]
great post. great comments.
i think as long as you’re writing code for somebody else, you will always feel the frustration of short-term thinking and cheap and nasty code. if you want to be a purist, either join a large dev team working on large-scale in-house projects, or start your own shop with your own software and take it from there.
i’m also tired of clients who want everything for nothing in little time. but i’m saying no to them more and more. you can see them coming from a mile away. i actually now ask how much their budget is up front and pass them on to my friends who do peanuts jobs if they don’t fall into my bracket. that way everybody’s happy. if you feel it’s worthwhile to take on, there’s ways to cushion the impact that their indecision can have on your productivity and profitability. i believe that the short-term sacrifice paradigm never actually pays off what it promises and always leaves you hopeful about the next possible job that’s going to save the ship.
sometimes, the product isn’t as important as the politics behind it – i like the observation about the “stamp” that execs like to put on their software. at the end of the day, you need to be able to read a client to understand what makes them happy. most of the time it’s to brag to their execs/buddies that they got some large company to do the code, or that they have some unique arb feature. if you can try to pick this up early on, it can help the project a lot. so learn to ask more questions about the personal motivations behind the project. this provides a context for the spec and can save you a lot of time and effort in the long run.
i’m also starting to use the ‘the software doesn’t have that feature’ excuse to bring clients back to earth when they ask for the limo that they don’t need or can’t afford… tell them you can do it, but that it’ll cost them extra to develop it from scratch. at the back of client’s minds, is always the thought that their cousin/somebody in the third world, could do it for much cheaper using the ubiquitous infinite-possibility-cms-framework. using this excuse nullifies that option.
of late, i’ve also been omitting / marking optional spec which i’d think as obvious. all that stuff that you would spend 80% of your time on but most users wouldn’t take advantage of. funny thing is that clients don’t notice because that’s not the most important thing for them. then when they finally realise that they need it after actually interacting with the software, you tell them how it’s a really good idea to add that feature and that it’ll cost them x. that way, the client feels like they’re contributing and they finally start to understand that the needs of the user are actually important.
i also always add a few optionals on the end of the quote at a ridiculous price. i make sure i’m making enough off the main project. if i get the optional bit, it’s a bonus. that way clients feel like they’re either getting a premium product, or they’re saving a lot or money. works every time, i swear.
Awesome post!
Story of our lives …. be it a small or app or a big project we have seen our software die even before it hits the market or end users, bad forecasting/planning/marketing, reasons can be plenty!
I agree with everything said, I felt like you were telling my story :)
[…] Is Good Code Impossible? Rapture In Venice (tags: career programming) EtiquetasCategoriasmiudezas Uncategorized […]
[…] blog is the second part of my post, Is Good Code Impossible?. In it, I go through a case study of a project with “Gorilla Mart” that illustrates how […]
Couldn’t agree more…
Just coming out the tail end of an 18 month version of this!
Originally a 12 month project, major changes by the client 11 months in.. so major, the only thing we saved was the UI… Which once we finished their major changes.. they also scrapped.. gah.
[…] in Venice (“The Web Experts!”) asks, “is good code impossible in a client-based scenario?” then details the question with a retelling of an excruciating client project. Not only is the […]
Thats some great basics there, already know some of that, but you can always learn . I doubt a “kid” could put together such information as dolphin278 suggested. Maybe he’s just attempting to be “controversial? lol
I know the feeling… Actually all seasoned programmers would know it…
On the whole, a very well written post and extremely funny… I am going to be passing this to a lot of friends :)
So Great! I need some infos in this post for my rapport de stage. Can i have your contact please? I need your permission to quote it :D. Anyway, That’s great job. Keep going.
Man, oh, man. Been there (well, not with GMart, but with Q**%@)…. but to me, it’s craziest that these tools operate this way since, in fact, it does nothing but damage the brand equity that they’re counting on to sell their lo-fi apps.
[…] little while ago I wrote a story about Gorilla Mart and, well, that beast of a project. It’s in the App Store now, and I got a chance to check […]
[…] 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 ProposalAs 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.more at http://raptureinvenice.com/is-good-code-impossible/This is one of my favorite blog posts of the past few years. I have re read it to get a laugh so many times, I cant remember. […]