His story will resonate with anyone who's written software for business.
At my very first "real" programming job, my boss thought that this was how you motivate programmers - take whatever the real deadline is and cut the time in half, on the theory that the programmers will take twice as long as you give them anyway. I was pretty upset by this, because by being lied to about what the real timeframe was, we made a number of unsound technical decisions thinking we didn't have time to do things right. I don't think being lied to caused us to magically be able to get an app out the door faster - what being lied to about the schedule actually caused was for us to produce code that wasn't a good foundation for future changes.
In practice though, given twice the amount of time there will not magically be a twice as good solution. And many times you'd find that the solution would actually be exactly the same.
Give me 24 hours to do a job and I'll do it, give me two weeks and I'll procrastinate for 13 days and then do it in the last 24 hours. That's exaggerating, but not by much and I'm not sure I like to know myself that much.
I think I had the same boss as you in my first "real" job...Thankfully the experience taught me to choose my employers more wisely in all subsequent jobs.
Do they not teach Defense against the Dark Arts at university these days? "We can incorporate that new feature, boss. What feature do you want me to cut? I can get you expiring coupons but the store locator will have to go. Your call, you get paid the big money to make the important decisions."
Joe Newbie says he can do it, why can't you. By the way you're up for your annual review next week, maybe you can find some time somewhere because this feature is sorely needed ;)
Big companies have their own way of dealing with that sort of thing, you might get away with it in a company where there are not enough people waiting to take your place (sometimes literally).
And you can only pull that one so often before it starts to look like you're using it as a way to slack.
Maybe a better way to do this would be to say you'd do both but it will have a such-and-such effect on the deadline we all agreed on when taking on this project. That way you don't have to make it seem as though there is only a 'you can't have both' solution.
The other side of this coin is that any programmer will normally speaking use all the ram, storage, run time, CPU cycles and wall clock time available to implement something.
And make sure you do that in email, not verbally.
Office politics like this is one of the bigger reasons why you won't find the best-of-breed programmers in offices like that, or at least not for long.
"Other people's inability to do basic project estimation has no bearing on the issue at hand."
Why is software the only field where people allow themselves to be bullied into ignoring basic arithmetic? I was in a kitchen shop the other day, and the sales guy had no problem rearranging things to modify the final price, but there was a list of components in front of us at all times, broken down by price. Pick and choose what you want.
That's exactly how software estimation works too. If you add something to the scope, it gets added to the budget. There's simply no room to do otherwise.
When you're in a restaurant setting the quality will suffer if you want more ingredients than the budget will normally allow. The end-result of that is McDonalds. In a software setting it is also the quality that suffers, the end result of that is visible all around you.
Software is rarely sold on quality, most of the time it is on features.
In the end, if quality software is your goal you'll have to open your own restaurant...
When you're in a restaurant setting the quality will suffer if you want more ingredients than the budget will normally allow. The end-result of that is McDonalds. In a software setting it is also the quality that suffers, the end result of that is visible all around you.
That's exactly how software estimation works too. If you add something to the scope, it gets added to the budget. There's simply no room to do otherwise.
There's a difference between the two examples in your metaphor which is extremely important.
In the case of the sales guy in the kitchen shop, he already had a known set of things to arrange with a known set of prices and a known set of discounts that he could work against. This is a lot of knowns, and very little estimation.
Now imagine that instead of having a known set of things, he offered to have built for you a set of kitchen supplies to match what you thought you might be making in your kitchen in the foreseeable future. The supplies you need may or may not already exists in the market of kitchen supplies.
For the supplies that already exist, estimation is pretty easy and accurate. Look at the price tags, and sum them, possibly picking out subsets in the process.
For the supplies that don't yet exist, estimation is anywhere from difficult to impossible, depending on the accuracy demanded. There is the time and cost of building the finished product, but there is also the time spent researching what that finished product ought to be, while balancing between the cost of the finished product and its effectiveness.
Software development isn't a matter of taking a set of solutions and finding an optimal set of subset. Software development is determining what that initial set ought to contain; it might contain some already existing subsets, which makes that part of estimation easier. But other elements you will have to create, and estimating creation time of something that doesn't yet exist is often a case in futility. It often simply comes down to a gut feeling, or intuition, or whatever you want to call it.
This is why people get bullied. If someone's gut says something is a particular way, but they are feeling intense peer pressure to believe it isn't that way, they'll feel compelled to distrust their intuition. Imagine, if you will, someone who believes the universe is billions of years old in a community full of people who believe it is only 6000 years old, at a time when people were just starting to discover evidence for this longer period; he'll feel strongly compelled to keep his intuition to himself.
sigh Even this example isn't perfect, because there is still something tangible to it. It's hard to find metaphors that do the nebulous nature of software development justice. Maybe someone else has a better metaphor they've had success with?
The situation Patrick sketches to me is reminiscent of a boss/worker relationship, not of a contractor one, but the same rules (with some slight modifications) still apply.
I used to make a living building software for fixed prices. To make a profit, I had to prevent scope creep.
My most effective scheduling tool was a list of proposed features, each with an attached estimate. The client suggested features, I estimated them, and the client chose the order of implementation.
If the client wanted to add, remove, or reorder features, great! We'd get out the list and make new estimates. The schedule and cost would change based on those estimates. By making the schedule highly "visible", and working to update it with the client, I gave them what they wanted (fine-grained control over "what" and "when" and "how much") without trying to stuff 6 weeks of features into 2 weeks. And if I estimated something incorrectly, I didn't charge for the extra work.
I can remember only one client who liked to bully his contractors. (He was also bad about paying his bills.) I wrapped up that project quickly, and politely refused any further work, even when he offered me a small fortune.
That's a fantastic way to do it. The clarity you built in to your approach is exactly the way to resolve this sort of issue, as soon as stuff is left 'up in the air' or is not made explicit the stage is set for some kind of conflict or disappointment.
By doing it your way instead of presenting the client/your boss/whoever pays your bills with a binary choice (this or that) you present them with a menu of items with an associated cost. They know their budget and you give them the freedom to expend it the way they think is best.
> And if I estimated something incorrectly, I didn't charge for the extra work.
Very honourable, and a really good way to show your customers you are confident and willing to eat your mistakes. Things like that will create a bond of trust between a supplier and a customer in a very short time, and you probably have sold to the same customers several times if that was your attitude.
>> And if I estimated something incorrectly, I didn't charge for the extra work.
> Very honourable, and a really good way to show your customers you are confident and willing to eat your mistakes. Things like that will create a bond of trust between a supplier and a customer in a very short time...
Things like that will create a systematic overpricing of contracts. That's not a criticism of the GP, by the way, just of fixed price contracts in general.
One alternative I have heard of is to present a list of estimates along with their uncertainties and possible risks. Keep the client up to date as any risks come to pass or are eliminated. That should also help to build trust between the client and supplier.
Also, you wouldn't want to turn a scope document into one containing mathematical equations and Heisenberg's uncertainty principle.
If there is no trust, no amount of documentation will help you. So unless you're Google suing Apple, clients that don't respect or appreciate your work are better addressed as ex-clients.
Not at all. If you shift all the risk from the client to the supplier then the price will go up. There's no free lunch.
Of course you could be the client who strikes the jackpot because the supplier underestimated the job - in which case you probably won't get a great result.
I agree that this is a very good way of doing things. And when you are a freelancer you should manage your clients and take care of things like this.
What bothers me though is when this happens (and at least for me it always does) in a corporate environment, where this is clearly managing and therefor the job of the manager.
I don't mind helping with management as well as doing the actual coding, but then I'd like this added responsibility to be acknowledged so that time can be allocated for this, and that my salary can be adjusted to be closer that of a manager.
Unfortunately at many workplaces I've seen management are mostly playing politics amongst themselves, and then occasionally bully developers into taking over full management responsibility when some developing is to be done.
A very similar idea underlies the Scrum framework (and probably some other similar) - an explicit product backlog with estimates from which the product owner chooses what to implement next.
Well, I'll admit, that is one risk that Japanese salarymen don't have to deal with. That said, are you sure that is realistic, and not just engineer-is-totally-terrified-of-confrontation talking? It is a seller's market for engineers, even at big megacorps. A manager would have to be insane to threaten firing over "We're going to miss that deadline if you add this", especially because firing guarantees that the deadline gets blown and everyone in the room knows it.
It doesn't have to be an outright firing (GP never used the word 'fire'), it could be that you'll get passed over for promotion or just given maintenance work until you leave.
Being taken off a project and being replaced with someone else isn't going to look too good either way, especially not if the someone else manages to do what you said couldn't be done (you're obviously sure enough of yourself that that would never be the case).
That said, are you sure that is realistic, and not just engineer-is-totally-terrified-of-confrontation talking?
I'd say it is more realistic in other places than it is in Japan and similar social cultures.
The limiting component is one's sense of honor and loyalty to one's company. In a culture where honor iand loyalty sn't so prized, a manager would have no problem firing an employee in an attempt to deceive people.
Sure, it might blow the deadline, and everyone will know that, but it will shelter the manager from responsibility. If the manager can intimidate the engineer into accepting the new feature on the old deadline, then the manager can claim it is the engineers fault for blowing the deadline. If the manager can't intimidate the engineer, and instead fires him, he can claim he would have hit the deadline if he didn't have such an incompetent staff underneath him. Either way, it's not his fault. Sure, it might screw the company, and it will definitely screw the engineer, but at least the manager is safe.
And yes, there are a lot of organizations like this where responsibility does not follow authority. But it requires a complete disregard for one's sense of honor.
From the conversations I've had with my dad regarding Japanese culture -- he was stationed there while serving in the military --, I get the impression this sort of dishonorable behavior is almost inconceivable over there. That might be why it seems so unrealistic to you. :-\
Uncle Bob (one of the founders of Agile manifesto, author or Clean Code and Clean Coder) commented this week (http://twitter.com/unclebobmartin/status/19904664214): Never allow a manager to convince you to break your disciplines in the interest of speed. It'll just make you go slower.
There's a lot to hate in this sort of passive-aggressive yet obsequious stance of project management. It is akin to the Agile practice of nailing notecards to a wall, and then forcing a territorial pissing battle carried out on that same wall later. It doesn't matter what is on the wall, but the surface area must remain the same, relative to some maximum achievable surface area metric we scoped out somewhere else, presuming ourselves to be perfect at knowing how long things will take.
It all seems so amazingly childish to me. But I'm not surprised; ask anyone from either party battling it out on the wall, and the response will be about as substantive as "they're such whiny little babies, and I need to cover my ass from their inevitable fuck-ups". So we force on them responsibility in the most condescendingly smarmy way possible, by recognizing and granting weight to their authority while at the same time sneering at it and throwing them binary decisions, as though that was the real problem.
The real problem is culture, not features. Only a small part of the rant the original author wrote was about the features of the product he was developing. A good portion about it was about a culture that didn't give a shit about everything else in code except the features; organization, readability, maintainability, and everything else don't matter. They knew full well that this was not a "throwaway" product based on the objectives they laid out, but used "throwaway" like this magic word that had no prerequisites, and was just a synonym for "finish it faster".
They could've asked for neither feature, and I would bet code would've still sucked, because developing maintainable code is far more difficult than slapping together a roughed-out, buggy first pass. But the culture believed as a tenet that maintainable code was not important; and that belief is probably about as easy to scour out as the outlandish beliefs of political pundits.
Adopting an attitude of defensive compliance would only make the culture within more vulnerable to bullshit like this. The culture was already based on childishness, and behaving like a child would add more validation to the culture. Bare in mind it's not the tone of the defensiveness I am calling childish, it is the content. The template response quoted by patio11 is just as childish, even if you imagine it spoken in a professonal, dignified tone. It deflects responsibility by way of establishing a very polarized power relationship between boss and subordinate, to where those words do not sound at all out of place. It is Bad Agile in spades.[1]
This sort of power relationship makes a lot of very important conversations that need to take place within a software project much more difficult and less likely. These aren't the conversations to do with culling or amending the feature set. They are the conversations to do with trade-offs based on the same feature set; they are matters to which the developers, and not the management, have the most knowledge and insight. But they can't happen when people believe that important decisions happen only certain places within an organization.
It was brought up elsewhere in this thread by patio11, and so I'll take a bit of latitude to say now that Japanese salaryman culture, and for that matter the bad facsimile of salaryman culture that American corporations seem to have adopted, is an extremely toxic environment for getting software written -- neverminding all the other things it is extremely toxic. It is a culture built on defensiveness and evasion of even the faintest whiff of responsibility for anything that requires any sort of discretion.
I think that it is this culture that is the fundamental problem, and that we keep trying to cure the disease by treating the symptoms. Salaryman culture doesn't even work perfectly for manufacturing, where there is literally no discretion amongst the rank-and-file. Things still go badly: the car still has brakes that fail, the toy still contains toxic amounts of lead, the plant still leaked toxins into the river nearby. How the hell do we expect it to work for something as obviously based on almost continuous acts of discretion like software development? This culture is broken, and we need to stop tacitly accepting that brokenness is inevitable and perpetual.
Or have we just decided the cultural battle is lost, and that we have to settle with whatever symbolic victories we can get to get through the day?
All coders should be schooled in the arts of negotiation. Sustainable pace is the only environment I will work in.
If a boss or customer is pushing for a new feature, the answer is to cut something else. Just because they want it doesn't mean they must have it. "But I might lose my job! But they might think I'm an amateur! But they... but...". No. Sustainable pace means working reasonably. Yes, there will always be others willing to say yes to everything and work insane hours. And they will continue to write crap code.
You've heard the old adage "Good, fast, or cheap. Pick two". Mine is "Good, fast, or cheap. Pick one, and it better be Good".
A valuable lesson indeed. Things to remember: 1) your client isn't spending their own money 2) if it goes well, they get the credit 3) if it fails, you take the blame.
Point (4) that I learned in the consulting business is, it's nothing personal. Part of your fee covers "scapegoat for hire". You're just an actor playing a role. You'll never run into those guys again, and it has no bearing on you getting work from that organization in the future.
My code is only good until someone rewrites it and makes it better. I can make my code easy to read and follow and do what it is supposed to do, and thus easy to rewrite. That is good code.
Good code is definitely not something intricately made by some Golden Design Pattern Rule argumented by a wise ass for hours just because he or she thinks his way/code is the best. That will on the contrary, and with high certainty, result in really crappy code.
Programming is not science, it's more like art - with one big difference. Code can be written to be easy to modify by other artists afterwards to their liking. If these artists can't modify or read other peoples code, but have to rewrite it completely there is a really big probability their new code is that of a newbie. It might be fancy and intricate, but still made by someone that lacks the ability to read, follow and understand old code.
Someone that can't understand "crappy" code, probably have a hard time even understanding design patterns - and have probably spent alot of time studying design patterns and memorized all their fancy names..
With all due respect, I think he failed horribly. How can you accept a project due in two weeks, and then afterwards learn about the basic requirements? If you're so obsessed with 'clean code' (a concept i doubt if it even exists), how can you miss out on software engineering basics like requirements gathering?
Because most of the people who buy (anything) are not professional (anything) buyers.
I've shot a few weddings and to make a viable business out of it and do quality work, you need to charge about a grand per wedding. Probably more, depending on various factors. Really, that's just how the numbers work out. One reason the wedding photography business is so tough is that the people who buy your services have no idea what's involved (all told, it's 30-40 hours work, once you have your workflow down, using fairly expensive equipment) and balk at even half that. Esp. since their friend with his first "prosumer" camera has told them he can do it for a tenth of that[1], and they're being ripped off.
So the question really is, how much do you need the work?
[1] He can't; he is in fact committing himself to giving the happy couple those 30-40 hours of his time as a wedding present. But he won't know that 'til it's too late...
Please tell me where those software engineering basics are written down. I'd really like to learn how to deal with clients that come up with new requirements along the way on a two week project with a hard deadline. That's not an engineering problem I'm afraid.
The question is, was it worth it? Did he get paid enough to feel well compensated for his frustration? If yes, then why all the venting? And if the answer is no:
You should always be ready to walk away from the deal. You don't have to accept unrealistic deadlines. If you choose to accept them, though, you don't have to allow massive spec changes midway. If you choose to allow it, you better make sure the money is good enough to compensate you for the massive horrible burnout you're going to put yourself through. And if you don't -- well, who else is to blame here? When you take a lot of risks, you get burned sooner or later. Don't make bets if you can't afford to lose them.
I think more people need to realize that if you can only win a project by killing yourself, it isn't worth winning. So what if it means someone else gets the gig — it wouldn't have been worth it if that's what it took.
Also, if think copying-and-pasting code and forgoing defining constants are tricks that will save you time, You're Doing It Wrong.
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!)
I don't understand why any of these are time-savers. Each of these tasks are things that might take you a few extra minutes now, but generally save far greater amounts of time almost immediately.
The example used in this article to come to the conclusion that "good code is impossible" is quite contrived. Of course you are going to end up with a shitty application and experience when you are 1) given almost no time to produce 2) given no technical help by the client 3) given no support by the client.
The fundamental problems aren't about code, they're in project management. Job shops occasionally strike a good balance, but inevitably bad clients drive out the good clients.
From time to time I think about a business model that works a lot like a job shop but tries to build equity in a software product line, learning from experience, continuous improvement, all that... But then I look at my 'sunk costs' and how I can get them back quickly to pay for my vision and I see the need for a 'moon shot' that maximizes the revenue I can get in the medium term... That's life, I guess.
This was a pretty funny story. I was kind of disappointed that it never got into the area that I was really interested, though: that of writing clean, maintainable, "good" code.
What kind of professional accepts a contract without a clearly defined scope of work? The author repeatedly talks about quality work, but I'm not sure he knows what that means. It sounds like the Big Company had a sucker on their hands, and they knew it.
At my very first "real" programming job, my boss thought that this was how you motivate programmers - take whatever the real deadline is and cut the time in half, on the theory that the programmers will take twice as long as you give them anyway. I was pretty upset by this, because by being lied to about what the real timeframe was, we made a number of unsound technical decisions thinking we didn't have time to do things right. I don't think being lied to caused us to magically be able to get an app out the door faster - what being lied to about the schedule actually caused was for us to produce code that wasn't a good foundation for future changes.