Slashdot Mirror
How Can a Programmer Make Everyone Happy?
Nuttles1 asks: "Ever since I became a professional programmer, 4 years ago, I have struggled with giving my superiors everything they want. For instance, I have a programming supervisor that stresses correctness in programming first, amount of time needed second, features third, but I also have upper management stressing features and amount of time needed first and correctness of programming a distant second. The nature of my job requires pretty strict deadlines so time is not very variable. So, things get done in a way that fits the time allotted. The problem is that I don't make my direct supervisor happy because of the time constraint shortcuts in correctness must be made. The other problem is that, because I perform within the time constraints, they think that the time constraint can either stay relatively the same or that they can be squeezed a little more. Upper management also expects the advantages of having a strict programmatically correct program (code reuse, loose coupling, ease of maintenance) and are at loss when things are less then perfect after the initial release. It doesn't seem like a programmer can come out ahead. I have read many books but they usually have a utopian viewpoint or view time to develop as a variable. In real life, how do programmers handle this situation?"
Well, from your narrative I see you've landed the ultimate professional progammer position: one where management doesn't listen, tries to squeeze deadlines, and thinks code more than anything else has to be correct (the unfortunate thing about that being your management, the least qualified to say, probably defines correct.)
And, forgive me, I can't help but notice but the word client or customer is not mentioned even once in the narrative which indicates an upside down world for delivering applications (not all that unusual, but still upside down).
Also, you mention superiors, try to be a little less humble, they're likely not. And, you talk about "upper management". When upper management has their uncalloused little fingers all the way down to your level in determining quality, ....
Ultimately, unless you have some strong ties, or visions of fast advancement you'd be no worse off if you looked around a little to see if there is someplace that seems a little more attuned to the real world and a little less pedantic about "coding".
aside: (but related) I first encountered how crazy a world it could be with my first big assignment. I had to sit down with my manager, and our client. The client described what they wanted, and I gave a thumbnail estimate, apparently to the surprise of my manager. Surprise number 1: my manager took me into "the room" and told me never to give an estimate to the client without his approval. (I might agree with certain aspects of this, but I was confident of my estimate and had sort of figured it was part of my responsibility.) He wanted me to double my estimate, and that was what we would base our charge to the client on.
I finished the project ahead of my original estimate -- adding enhancements and extensions to some software we'd purchased from a sister telcom. When I delivered it to the clients, ahead of schedule, I pointed out that part of the original output of the original program was just garbage, i.e., there was no code written around that output, and it had no correlation to the rest of the report. The client knew already and told me they always just ignored that part of the report. I asked if they needed or wanted that part of the report, and their eyes just lit up. So I offered to deliver yet a different version of my code which included a fix for the broken part of the old application. The client was ecstatic, a glowing letter ensued.
My manager took me to "the room" again. I tried to remain calm, waiting for the accolades, perhaps even a bonus? But, he pointed his finger in my face and said, "Don't you ever deliver more to the client than you say you will!". Stunned silence.
You should report to one mananger, and one manager alone. That will also be the person to assign you work, and give you priorities. That will also be the person who gives you performance reviews. So you better do what that person says. You have no business following low level directions like "what programming methodology to employ" from upper management. And upper management definitly has no business telling you how to do your job.
:)
Well, in a perfect world, that's how it should work.
This is not so much a programmer problem but just a business problem; also known as a people problem. Just substitute programming with any other job description and you have the problems everyone deals with on a daily basis. There is no right or wrong answer only the relationships you have to deal with.
Quality Hosting e3 Servers
Insist the "higher-ups" go through your direct boss. Not every boss will protect you this way, but unless it's a really small startup, they should, IMO.
The clearance system sounds logical. It is not. It is completely arbitrary. -- John Bolton
Here's the thing, just deal with it for awhile. Make some money, and then leave for another job that has smart people in charge. Wannabe programmers that are in management just screw everything up cause they think that if they follow the one guideline they remember from a 900 page development book they read in 1983 while studying COBOL, that everything will be perfect. Chalk it up as experience, or "paying your dues", or if you're past those points in your life, deal with it or move on.
Now of course, if you're working on some important systems like aviation, military, or any of the MMORPGs I play, then shutup and get back to work.
There are several things you should consider:
* "Dead lines" are never really dead lines. They are just guidelines to when you should reach something that works (not works well). The management (or a good management) always takes into account you probably won't make it in time anyway.
* Good design and code re-use are there to save time, not to waste it. Take the time doing things right, and it will save you time in the long run.
* You should always please whoever controls your future (but first, yourself).
|| Geshem ||
...use the ice-pick on a piece of hell for my drink.
You can't make everyone happy, nor should you try.
Delegate - upwards, sideways, anywhere - everything that is not your responsibility: business analysis, requirements definition, project planning, test planning, and steer clear of the politics.
Insist on written documents, version controlled, reviewed and signed off, to show your supervisor what the constraints are.
You have to deliver to the company's scheduling needs, and you need to keep the quality as high as possible.
Anything you can add at the technical level is only a bonus, unless you can explain it (in tech terms) to the business as a benefit to them, and they understand, and care.
Now, for the important question:
How can you make YOURSELF happy?
(otherwise, what are you doing it for? - and don't say paycheck, 'cos there's a balance and money ain't everything)
After 10 years in the industry, I've got the following three methods:
1. Do everything everybody asks you to, even if you personally think it's contradictory. Works in companies that have a strong chain of command, but results in code you would never want to include in your interview portfolio. And gets you targeted for first layoff.
2. Go your own way, but do plenty of software engineering to back things up. Gets you targeted quite often for layoff, but since you have the numbers, you rarely get laid off- this method has resulted in up to two years in the same job for me. Results in code you can be proud in, but you'll never meet a deadline, and that will eventually get you fired, so to give yourself extra time always multiply all estimates by 4 (Scotty school of engineering).
3. Give up, and offshore your job. Everything gets coded exactly to spec, even when the specs make no sense, and nothing gets done right- but at least you'll end up doing what you're told, until your bosses find out, and then they cut out the middle man (you).
In other words, I've yet to find a winning method in the situation you describe.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
"I don't know the key to success, but the key to failure is trying to please everybody."
Please the boss that can give you the raise and fire you.
include $sig;
1;
Go to your supervisor and offer them that you will work for less, and you will work long hours as well.
It certainly will make them happy for a while. Let me know if you succeeded and I'll share more ideas with you like offering your girlfriend and your sister to them, drive them to work and do the shopping for them.Come on, they earn xxx$ in every minute on you. You should start your own business, be your boss and then you easily can answer this none-sence question :)
A good way to deal with conflicting bosses is to make them agree.
Or maybe it's just your job to write correct software with lots of good features in a fixed amount of time. Get it done or you're fired.
if you think you're really pulling it off in the deadline set, yet you're not achieving management goals, then you've got a clear and distinct conflict between what it is you have to deliver, what you have delivered, and what you don't need to deliver.
.. that you are asking non-managers how to best communicate with managers indicates that you're definitely off the rails a bit. you and your managers are supposed to be your team, not slashdot.
go to all three echelons, ask them these three questions: what is it you have to deliver, how can what you do deliver be better viewed and thus managed, and what do you not strictly have to deliver? compare their answers to the reality of projects you've completed and are not actively working on; don't do this for current, scheduled projects, however. its a strategic assessment you're doing, not a tactical one, so maintain that distinction.
generally, programmer delivery is a dynamically defined subject; going to management serves as advice only inasmuch as you actually get your delivery properly defined. it sounds like you don't quite have it as neat as you may think you do
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
IF that's the situation you're in, then first and formost, your company has a HORRIBLE corporate culture for development. If your boss and upper management are not in sync as to what's important, then I recommend you do what your immediate supervisor wants. If upper management has a problem with what you're doing, refer them to your manager. Your manager isn't there just to give you work to do, but he's also there to act as the sh*t filter and keep you from being swamped with all the other political crap that happens in a company. That's part of what he gets paid for.
Only other option is find another job where things ARE done correctly and management is all on the same page.
Sorry, just thought this fits too perfect:
Peter: It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? And here's another thing, I have eight different bosses right now.
Bob: Eight?
Peter: Eight, Bob. So that means when I make a mistake, I have eight different people coming by to tell me about it. That's my only real motivation is not to be hassled, that, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
The ratio of people to cake is too big
Instead of trying to be dudley dooright, try to adopt a new prespective that allows you to maintain your sense of self.
If, as you represent yourself you need to approach things idelologically then try...
"Pragmatism is a school of philosophy which originated in the United States in the late 1800s. Pragmatism is characterized by the insistence on consequences, utility and practicality as vital components of truth. Pragmatism objects to the view that human concepts and intellect represent reality, and therefore stands in opposition to both formalist and rationalist schools of philosophy. Rather, pragmatism holds that it is only in the struggle of intelligent organisms with the surrounding environment that theories and data acquire significance. Pragmatism does not hold, however, that just anything that is useful or practical should be regarded as true, or anything that helps us to survive merely in the short-term; pragmatists argue that what should be taken as true is that which most contributes to the most human good over the longest course. In practice, this means that for pragmatists, theoretical claims should be tied to verification practices--i.e., that one should be able to make predictions and test them--and that ultimately the needs of humankind should guide the path of human inquiry."
Pragmatisim is all american and grew from the camps of Dewey and James. It's good stuff to navigate by. It's closely related to...
"In the philosophy of science, instrumentalism is the view that concepts and theories are merely useful instruments whose worth is measured not by whether the concepts and theories are true or false (or correctly depict reality), but how effective they are in explaining and predicting phenomena." Both are alittle out of vogue but the object of my recommendations is to allow you to keep your ethical high ground and still survive.
Ultimately, don't worry, you'll age and grow cynical, learning to survive.
You need to be honest with yourself and determine how good you are, then move on. It's not worth trying to fight a system like you describe, and if you are in the top half of the talent in the industry, there's a job out there for you that's more interesting, pays better, and isn't half as painful.
If you're in the bottom half, I guess get used to it and be happy you're employed.
Slashdot - where whining about luck is the new way to make the world you want.
Lets get real here. The stiuation is bad, your'e not in a position to change it. Ask yourself who writes your performance reviews. Talk to them. Find out what they want from you. Give it to them. Wait for your review and then either move up or be prepared to move away.
Sometimes you just have to be your own best friend.
You deal with it the same way anyone else with a job does: you learn to set, and meet, proper priorities.
An employee's job is to satisfy your manager's expectations that you are fulfilling your duty within the organization. This is true for anyone with a job, no matter what that job might be -- programmer, sysadmin, manager, garbage collector, whatever. It's true for anyone with a boss -- and pretty much everyone has a boss, whether it's a manager, a VP, a board of directors, the voting public, whatever.
According to you, your manager expects you to, quote, "that stresses correctness in programming first, amount of time needed second, features third". That's it then. That's your job. Period. If your manager is doing his job, then that's all you should need to worry about.
Your manager, by contrast, is responsible for fulfilling the expectations of upper management, namely, in "stressing features and amount of time needed first and correctness of programming a distant second". In practice, that means that he has to walk the balance between doing things right by his staff -- code correctness, then time constraints, then feature completeness -- and doing things right by his bosses -- features & time, then correctness. His job is to allocate staffing resources so that his team is doing things properly and at the same time keeping upper management happy.
The concerns of staff two levels up the chain of management aren't your problem; they need to be steering the direction of the business, and counting on the people working under them to be able to deliver. Likewise, the constraints that you need to be working within -- doing your job right first, and meeting time & feature needs second -- should not be the concern of the upper management; they have broader things they need to be focusing on.
Now, I realize that this is kind of idealized, and not all companies provide an environment where this is possible. Some companies are led by people that want to be very hands on with what their staff are doing, and sometimes that can even be a good thing. Other companies want to break down barriers between layers of management and staff, and that can also be a good thing. But having too many cooks in the kitchen, to rob a phrase, is rarely a good thing. If your company is big enough to have multiple layers of management, and they trusted your enough to give you a job, then they need to trust you to do that job, and they need to trust your manager to set your working priorities, and they need to focus their own efforts on steering the company itself so that you have something worth working on and the long term prospects of the company are assured.
And all that said, the one theme common to all of these different job functions is that everyone has to be able to understand and set priorities. In these days of relentless cost cutting and ever-increasing productivity, most people have more job responsibilities today than people did a couple of decades ago. The people that keep their jobs and keep getting promoted are the ones that figure out how to doing their immediate job right (so that it makes their direct manager happy) and making their manager's job easy (so that it makes the upper level manager happy).
And part of this means figuring out how to manage your time, what to focus your efforts on, and what parts of your job can be safely ignored. (And yes, implicitly, that means that some people won't be happy; you have to learn to live with this, unfortunately.) If banging out a sloppy version of your code gets something to your managers in a third the time that the "correct" version would have taken, then sometimes that's the compromise you have to make. But if you can make the case that spending the extra time to do it "right" will have benefits that offset the lost time & functionality -- for example, it can make future versions faster to produce
DO NOT LEAVE IT IS NOT REAL
The software development triangle states that features (and, I suppose, the overhead of developing to whatever standards your managers happen to define as "correct") are balanced against resources and time. If you want to give a programmer less time, give him more resources (money, more developers, etc.) or accept a less sophisticated program.
:)
It sounds like your managers aren't respecting this principle, and perhaps the only advice I can give you is to talk to them about it and/or start looking for a job elsewhere
Not to be too pessimistic, but no matter how large the project is, no matter how important it is to everyone involved, it will be faster to slip it now and get it done right than to fsck it up and need to do it over.
Projects slip all of the time. Someone is setting up how much time you have. Time is always variable, and is negotiated with outside entities. Your boss's boss, the loonies in marketing... someone is setting the schedule. Schedules are always optimistic. The bigger and more important the project, the more likely it is to slip.
The key is not to do what people want, but what will make them happy. Your immediate boss probably wants Stanford dissertation level code, but would be happy with good documentation and re-usable classes. Your higher-ups may want it done fully featured last week, but would be happy if you explained that the extra time you spent now can save a week off of all of your other projects. And if you can only make one person happy, tell everyone else to go to that one person. It takes guts to tell a high-level executive to talk to your manager, but that's what it takes. And sometimes you have to tell your manager to talk to the high-level executives. But if you can't make lots of people happy, make one person happy, and tell everyone else to stuff it on their authority.
Most importantly, the code you make should make you happy. If it doesn't, it isn't going to please anyone else. More importantly, though, you're selling your company your time and experience, not your soul. If your experience (however young) says to do something differently, that's what they're paying you to know. And if it's your soul they want... just recognize that a wall-street banker can make upwards of 200,000 dollars their first year. Souls go for a lot more money than you probably make.
Either way, you're getting laid off in 5 years. Good luck!
The ______ Agenda
Check it out.
Nuttles1:
p2sam: You should report to one mananger, and one manager alone... Well, in a perfect world, that's how it should work. :)
Just be completely honest and forthright in all your communications.
Suppose you have
Then your emails would read like:Start looking for a job, since management will outsource you when you can't be squeezed any more.
let's just say, dead people don't have expectations..
(dramatic) *DUN DUN Dunnnnnnnnnnnnn*
Nuttles1, I told you I needed those TPS reports by last friday. You are so not getting a raise.
Oh, and uhmm - I'm gonna need you to work a full day Saturday.
Yeah... That would be great.
Rob Enderle's excellent new book: Everything I needed to know about Computer Science I learned in Marketing School
Surprise number 1: my manager took me into "the room" and told me never to give an estimate to the client without his approval.
My manager took me to "the room" again. I tried to remain calm, waiting for the accolades, perhaps even a bonus? But, he pointed his finger in my face and said, "Don't you ever deliver more to the client than you say you will!". Stunned silence.
This is just atrocious management.
A good manager would have practiced [over and over again] the interaction before he ever let you meet the client face to face.
For example, he would have stressed things like
And then he would have gone through practice conversations in which he pretended to be the client, and he coached you as to what to say and what not to say, and how to hem and haw your way out of making any firm commitment [until the "correct" answer could be cleared by accounting].Your manager not practicing a client site visit like that with you beforehand, and then admonishing you afterwords, would be like a football coach not teaching his playbook to his players during practice [or never even showing them the playbook in the first place], and then yelling at them after the game because they were clueless on the field.
This is the first good "Ask Slashdot" I've seen in a long time.
I wish I had an answer to give you. Since your immediate supervisor is a programmer, just try to level with him and keep pleasing his superiors. Hopefully he'll remember having to cut corners and crash a project... if not, maybe he was kicked upstairs because he couldn't meet his deadlines....
Vanya's Law: "In any culture without irony, fart jokes will be the highest form of humor."
You do what your immediate supervisor or line manager wants you to do. If upper management don't like what you're doing then they have to deal with your supervisor to fix it, not you. To a certain degree your supervisor is there to help communication across the heirarchy of a company, if the upper management take the issue up with you directly then your supervisor isn't doing their job properly. You shouldn't be worried about what upper management think, your thoughts shouldn't even consider anything past your supervisor. If upper management approach you with their ideas then you should be responding "I'll discuss it with [insert supervisors name here]" because you should be respecting your supervisors position within the company.
That said, unfortunately most upper management people are psychopaths, especially in smaller companies. So unless you want your tires slashed by the CIO you'd better start counting your lines of code...
Task Mangler
In moments like these, I recall a certain Dilbert strip, where pointy hair boss tells Dilbert:
PHB- This project is impossible and can't be done.
D- It's finished.
PHB- The project will never work like this.
D- It works perfectly.
PHB- There's a spelling mistake here.
D- That's a number...
http://superconfigure-supergroove.appspot.com/
Well, I was going to post an angry missive about how the IT industry is going down the toilet, and "correctness" is going out the window, but it looks your boss is spot on: strive for correctness *first*. Make sure you have unit tests striving for 100% coverage. Make sure the database has full constraints. Make sure you have actually studied the relational model if you're in charge of it. Make sure your code is clear and simple and well-thought-out. If you had to write code in a hurry, THROW IT AWAY and write it anew (maybe test-driven this time).
And the other piece of advice is: always do what your immediate boss wants, let him report to HIS boss.
Looks like your solution is easy. Just do what the super says. And if he starts saying that correctness isn't important, but "shipping" or "features" are, find a new job. Don't pollute the IT industry with more insecure, crash-prone garbage.
KEEP YOUR CLOTHES ON.
(Please, for the love of god.)
"Every decent man is ashamed of the government he lives under." - H.L. Mencken
"For instance, I have a programming supervisor that stresses correctness in programming first, amount of time needed second, features third, but I also have upper management stressing features and amount of time needed first and correctness of programming a distant second."
Simple, do as your immediate supervisor tells you to do. It's his job to worry about what the upper management says, to worry about the deadlines, to worry about budgets, to protect you from upper management interference and stupidity.
You should only worry about what upper management is saying if your supervisor is unfair, incompetant, or you want to steal his job.
John.
I would say that your direct superior has the responsibility to make the case to upper management that code quality matters (I would agree with his priorities, in fact!). This is, after all, the supposed point of a management hierarchy.
Slashdot is really the wrong place for this sort of discussion, but here goes: It sounds like you're working on a product that doesn't have a product manager. The way it's supposed to work is that the product manager decides what goes into the product and coordinates with the developers to come up with a realistic schedule. Anyone who has a request should be talking to the product manager to get it into the schedule.
Seriously, I am a lowly technical lead of a team that usually consists of just me but grows to 3 or 4 people for a few months during "crunch" times. My management is required by our documented process to ask me how much effort something will take before it is approved. If the deadline cannot be met, they add staff well in advance or slip the change to a later build.
This space intentionally left blank.
A good way to deal with conflicting bosses is to make them agree.
There's a very important point in here. Your bosses are not constants, they're variables (well, that's one way to put it). If they're fighting each other through you, you need to get out of the friggin' way, or end up as collateral damage.
If your direct boss tells you to do X, and his boss tells you to do Y, right away you should point him to your direct boss. "I'll let you two sort this out and get back to me." Neither one is necessarily "right" or "wrong", in that different customers expect different things and will react differently to on-time crappy software vs. late excellent software... and there's sometimes a trade-off in writing lovely reusable code that's good in the long-term vs. hasty NON-reuseable code that gets the project out the door and money in the bank short-term.
There's also the trouble that some programmers who are told to "design for re-use" will bog the project down into eternity with bloated "handle-every-possible-case" code, while others will simply spend a little more time thinking and come up with an elegant solution that's *smaller* than the one-time-only hack job, and reap the benefits in the very next project. And alas, the average programmer without strict oversight falls mostly into the former camp. So it's no simple answer.
But these are business decisions that your boss and his boss need to sort out. You should just indicate that you understand that these issues exist, and suggest (in a friendly way) that they do their jobs.
Number one montra in business application development. "I'm doing this for the user"
;)
.Net are likely the most widely used and have a collection of the greatest tools (sorry Java guys, eclipse just doesn't hold a candle to Visual Studio). One of the greatest things about developing in .Net is that we (finally!) get true object inheritance. And while people smile and nod and say isn't it great with out knowing why, I can tell you, I can't imagine coding with out it. One of the few things I really agree with Joel Spolanski [sp?] about is code up front. It takes longer to build a completely abstract data layer and impliment a standardized data object (using inheritance and abstract factory classes), but the advantage of having a DLL that can be inserted into any project and give you immediate dev time access to database metadata is immense. Having a series of base classes to handle the user interface, threading, data access, business logic, etc will save significant time in the long run.
Remember that. The user (customer/client/employee) defines the features they need. These features form the basics of the requirements document.
Your tech lead/analysist/coordinator is going to ask you for time estimates. Business sciences says the way to find this number is to find the Optimal time(a), the most likely time(b), and the worst case time(c) and apply the following formula:
Expected time = (a + 4b + c)/6
If I think I could get a roughed out edition together in 8 hours, I would use a=8, b=16, c=58 for an expected time of 22 hours. You to can sit through hours of business science and learn this too, or just use the old addage of "triple it!" and quote 24 hours
So, you kick that number back to the coordinator. The coordinator looks at other projects on your plate and priorities and sends a time estimate back to the manager.
That should take care of the deadlines and feature set. You have a rec document, and a schedule. Next up was code style. Most current business office application development is going to be in a RAD environment. VB and
Our apps now our no longer even apps. We run a portal like interface, and when we receive new user requests they get developed as modules that are simply plugged into the existing system. Here are some out dated, but still handy looks at the type of design we use.
http://ringdev.com/code/GFCTeirDesign.gif
http://ringdev.com/code/GFCNamespace.gif
Once you have a code base. Developing new apps is significantly easier, faster, and the code you produce is more stable. So your tech lead is right, code correctness is very important.
And finally, don't be afraid to say no. I have 3 tiers of projects. Immediate, Down the road, and Ignore. If my coordinater drops something on my desk with a very low priority and a very large work load, I usually tell him I'll take care of it right after I clean my desk. Which usually implies that anything on my desk gets round filed. It is your manager and coordinater's job to take care of scheduling. If they are putting to much on your plate, sit them down, prioritize, and give back.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
We drink.
I was a professional developer for seven years, and I've got three words for you:
Get Out Now.
If you have a single manager that you must answer to, talk to him or her, and ask them what to do about this situation. Asking on Slashdot is unlikely to get you the help you need. Your immediate manager might be able to intervene on your behalf, and insist the other managers go through the proper channels. If you have multiple managers, or your immediate manager can't help, the organization is probably dysfunctional anyway and your career will be limited by this dysfunction if you like it or not.
You have a choice, you can please some of the people, all the time, or you can please all of the people, some of the time. But you'll never please all of the people, all of the time, and trying to do so will only cause you problems.
I used up all my sick days, so I'm calling in dead.
After reading all of the sibling posts stating that you shouldn't have done anything extra, and that your manager was right to criticize you for making its customer happy, all that I can say is that if that type of thing is a preferred standard American business practice, then it's no wonder that our country is going down the toilet.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
I explained the problems you're facing to my wife.
She said "How long has he worked for Microsoft?"
After giving it some thought, she suggests "get some balls and ask your boss exactly 'what do you want?' so that you can cover your ass, preferably by email and when the higher smucks express displeasure, hit the print button."
She goes so far to say you should include the higher smucks in that discussion of how it should be done. Carbon copy them in the email if you're emailing.
Disclaimer: I am posting her suggestion because she has been in this type of situation and came out well. Personally, I see a danger of tanking evaluations and having to keep an eye out for the next job.
B) Eliminate all the stupid users. This is frowned upon by society.
Given you indicate your deadlines are inflexible; time is a constant and can only be considered top priority. I wouldn't even call it a priority, but a requirement, as it is something which cannot be compromised on.
This leaves only the features/quality priorities to be listed; let your managers battle it out together. I dare bet that "features" will be top priority, since that's what customers pay for.
In my job we have such priorities too; listing quality first, features second and time third. When it all comes down to it, products will be released without quality if it means more features, and without features if it means reaching a deadline.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
In my last job, I was in a situation where I had two bosses. Boss A wanted me to to do my job using method X. Boss B wanted me to do my job using mathod Y. I liked and respected both bosses and could see the benefits of either method A or B to complete my task. When bosses A and B were in the same room, violent firestorms of loud cursing and office furniture throwing ensued. I completed my assignment using method C, an ugly amalgam of methods A and B because I wanted to please both bosses.
I've been unemployed since then. Pick one boss and please him or her.
My major objection to the GP post was that he gave an estimate on the spot. That is something all of my guys are schooled NOT to do on the occaisions they do talk to clients. There are several reasons for it, among them are:
Any non-trivial project needs to be reviewed to make sure that nothing was missed.
I run their schedule. It's nice that you can get this done in 2 weeks, but we already promised client Z that we'd have this other thing done by the end of the year and it's probably going to take you the next 2 months to do it. I'm going to have to assign this to what's-his-face instead and I know he can't get it done in less than a month.
There are also problems with providing extra features. The QA time has to be scheduled too, and they've only been given enough time to test the features you were supposed to write. They don't have time to work on the extra piece you added. Oh and by the way, we hadn't implemented that yet because the only approach that wasn't a maintenance nightmare was outside the amount the client was willing to pay for. Thanks for including it in a difficult to maintain way, now I need to budget for extra staff to support this that I hadn't planned on needing.
Tell your management what your estimates are. Tell your management what extra features you think you could put in. Let them decide what goes where. They're looking at a different picture than you are.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
Ah young Grasshopper,
You have now reached a maturity level in your career where you will be able to read books like 'The Mythical Man Month' and understand them. With that book, you will first be shocked by the fact that someone has written so clearly on these issues, and then you will be shocked to find out he wrote it most likely before you were born.
Read the following books, in the following order:
The Mythical Man Month
The Rise and Fall of the American Programmer
The Pragmatic Programmer
After the Gold Rush
After the Gold rush is out of print with a second edition coming out soon... a while back some of the chapters from the new edition was available from the Author's website. In any case, pick up a used copy if necessary - it will be worth it.
The problem is, managers should reads books, and studinig this situations, the job of them to solve it and not yours..
h tml)
;)
There are many books around it, but I believe, you should give books into your boss's hands, and wait for his reaction, if any..
Like one of the best for it about how things going on nasa software teams.. why could they write the Level5 code, with 99% of bugfree code.. and timelines, whatever.. and mostly how to manage the employee to do good job..
Check out:
They Write the Right Stuff (goolge)
(http://www.fastcompany.com/online/06/writestuff.
If your boss do not care about it, why would you? Just leave him in peace.. And now you know, what sould you first check about a new boss
There is only one good solution: The simpliest!
Talk to your line manager. In a private meeting, explain the compromises you're having to make in your work. Explain that the code you're being forced to release is unmaintainable, is prone to be bugged or poorly-structured because of the time constraints being forced.
Explain a compromise where you get some of the time you want in return for some of the code quality you want. You'll never get all the time you want but, if you can convince your boss that it's going to be of overall benefit, you might get enough.
Most importantly, if the shit hits the fan and your product comes back to you, make sure you're absolutely realistic with management about why this has happened. Yes, the code was sub-quality. Yes, the design was insufficient. Yes, it's management's fault on both counts for not allowing enough time for the proper running of the project.
One of the main problems is that a typical lifecycle (specification, design, implementation, testing) makes no sense to management. Even a technical manager will try to rush the specification and design so they can have demonstrable progress - something to show the client, even if it's not been thought through. And, as soon as the product looks complete, they'll want to get it out where it makes money, regardless of how thoroughly it's been tested.
Educating your superiors about the reality of these things is hard work. You might have managers that will - slowly - learn, in which case you may make some progress. Alternatively, look elsewhere: it's one of the most subtly self-destructive things, to be stuck in a job without being given the opportunity to do it well. Find somewhere that gives you that freedom.
You may have overstepped the line, but that wasn't your fault - your managers didn't manage to inform you of the rules.
But what you did choose to do is something that you should be proud of - you choose to be as helpful as possible. It is a rare thing and good to see, and the fact that you got lambasted for it is utterly disgusting.
The manager is right from the perspective of a largish company that acts like a largish company. A (successful) startup, or larger company that acts like a startup would never act like that. Overcharging customers is bad business, regardless of whatever industry euphamisims the parent's poster uses to describe it. Delivering a product that exceeds the customer's expectations is good business; in many cases, it's a good way to end up with more business that you can handle.
New Job
On the contrary. IME, people/organisations that truly understand the value of good design and best practices are usually very successful in the commercial world. This is precisely because if you take a longer-term view and keep your house in order, even taking a small hit in the short term to do it, then in the long term you will be vastly more productive and your products will be much higher quality. This is why they're "best practices".
It's the people who pretend (or honestly but wrongly believe) that they are following good practices because they read something in a book somewhere who usually cause the problems in the commercial world. They take the short term hit -- and usually it's a bigger hit than it needs to be -- yet fail to realise the longer term gains that should result. This is why not everything that comes with a chunky procedures manual is a best practice; indeed, IME most best practices are remarkably simple things.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
accept the little fact that you cannot. it'll help you mature a bit.
For the record (and I haven't responded to the others, but finally, I need to respond to at least one)...:
Ahem, for the record, at the session with the client my manager turned to me and asked me how long I thought it would take. That was when I gave my "estimate". When he chastised me later it was for offering such a short estimate, way too short in his opinion. (I know I didn't make that clear in my original post.) We discussed it, always in a civil manner, I stood by my opinion I could deliver in my estimated time frame but relented to his insistance I double the estimate for an official estimate for our client. I STILL finished in less time than my original estimate (including the fix of the other part of the code).
As for that "other" fix... it wasn't something they had to test -- it was functionality they had long since abandoned as being something useful. It was a "dead zone" (3 lines per item) on the report they had learned to ignore because the data in that zone was incorrect and useless. The fix I applied took little time, and little effort, and did not put at risk the estimated delivery date (the DOUBLED estimate).
We had an ongoing relationship with this client, essentially a locked in deal (their organization was part of the same umbrella corporation). Their list of needs and projects was virtually endless so it wasn't as if finishing this in half the time cut into our revenue stream.
And the good will from this extra effort was returned in full. Our relationship with the client went from adversarial to collaborative. They LOVED the results they were seeing, and changed their attitude and demeanor with us. (They literally used to sit in meetings with scowls and arms crossed, distrusting every suggestion, estimate, etc. we proposed.)
All in all, I was quite surprised at the beating I got for my post. Not so much that I got beat up, but that these attitudes are so pervasive. Maybe I didn't elaborate enough to give enough insight to my environment. But, I believed then, and I believe now the sum total of how we all do is a result of how hard we try to do good things, not how hard we try to maximize "controls".
(example: a while back I drove to a tire service store well known for its service -- I'd never been there before. I had a low-speed wobbly steering wheel problem. I pulled into the lot, and they literally ran out to my car (an advertised "service philosophy" of theirs, but a surprise to see it as real) and asked me what they could do for me. I described my problem, they took my key and immediately put my car on a lift and did some quick diagnostics. After some tweaks and adjustments they returned my car and told me it should be better... and if there were any problems, to bring it back. No Charge! And, the steering wobble was gone!
Less than a year later I needed new tires -- guess where I bought my new tires? The good will they brought more than offset the $50 I could've save at Costco... I'm a loyal customer.
Whenever your bosses ask for something outlandish, tell them that it's either virtually impossible or will take you a really long time to do it, but that you'll start on it anyway. Then, when you finish in three days, they'll think you're a miracle worker ;)
This is simple. Go to your boss & explain that the someone is putting pressure on you to choose different priorities than he has set for you. Be specific about the people & the issues. Ask him what you should do.
If he tells you to ignore the others, make it clear to him that you expect him to let the others know the priorities he has set for you & that any concerns should be addressed to him. (A good manager will have already told you that he's going straight to discuss them matter with the third party/parties.)
Let anyone who tries to set different expectations for you know what expectations your direct supervisor has set for you. Tell them that, if they have a problem with that, they either need to talk to your direct supervisor or change whom you directly report to.
If that doesn't make things better, let them know you aren't happy & start shopping for a new job.
They'll think that you've been padding your estimates, and will start setting unrealistic time constraints (as the management in the original poster's question has been doing).
... and I'm speaking from experience. I had the same sort of situation as the original poster, and I asked for clarification as to whom I was supposed to be reporting to -- the answer I got back was 'any manager with an emergency'. I asked who defines what's an emergency, and asked if it was only (insert list of 38 managers in our division), or if it applied to the whole company.
When you're dealing with management like what is described, if you manage to finish it in 3 days, you don't want to be seen as a miracle worker, or they'll start dumping you on multiple time-critical projects, each with timelines that are unrealistic if you were dedicated to them full time.
Do the good work, do a good job, but if you're dealing with idiot management, as was described, you'll want to make sure that you write some extra unit tests, and review the documentation a half dozen times for spelling errors, so you don't come in too far under your estimate.
Oh
If you're in that type of situation, get the hell out as soon as you can -- it's not worth the stress. Sure, it's nice to sit back and relax while you're collecting unemployment for a 'use of sarcasm' incident (it's a long story), but it's easier if you never let it get that far.
Build it, and they will come^Hplain.
The problem is not a technical one but rather business. What's helped me more than anything was learning to negotiate. I'd recommend "Secrets of Power Negotiating" by Roger Dawson which you can probably get from your local Library (I prefer the audio cassette series).
Ruby on Rails Screencast
You have to learn to accept that the people around you aren't going to all be happy no matter what you do. Life isn't a contrived puzzle with a well defined unique solution. Sometimes you just have to go with the best in the circumstances, and that is often far from some hypothetical ideal. If you can't deal with the idea that one of the people you deal with is going to be unhappy that you need to find a new job or develop a thicker skin.
Your Manager was an ass.
I've been lucky, most of the time I work with the customer directly, they have far more work than I can ever get done so things are simply prioritized and I do what's next on the list. I don't have to worry about a Manager demanding a different estimate from me than what I would say to the next person in the chain.
But I have seen instances of exactly what you describe.
As for customer expectations, here's my story:
I was once asked to go to a meeting with a client, one for which I did very little work for, but the company I worked for had a major project on the go for them. I was involved in the back-end helping our developers get a handle on the project and deal with a few technical issues which came up. (This wasn't my job per-say, but something I helped with since it was interesting.) One issue was printing of forms with the Forms software they were using.
So two of us went to the meeting with the customer, the customer included the IT Director as well as their 'Arts' department. The client insisted they wanted professional looking forms, and then showed mockups they wanted duplicated. (Which is exactly what one expects and hopes for...)
The department which created the forms insisted they were easy to print, and that they could provide an EPS version of the forms without difficulty; and since the forms software we were going to use supported EPS images there wouldn't be any problem using it.
They then asked why we refused to support this process, when the 'Arts' department insisted it would be EASY.
I had to explain to their 'Arts' department that the Forms software didn't print the EPS file, it merely sent it to the printer as-is. The printer had to be capable of interpreting the EPS data, and that unless they would guarantee that all the printers, including the ones in the warehouse (for Bill of Lading, Invoice, Pick list, etc) could print Postscript directly that we needed a different method. (Postscript being a $700+ option on most Lasers at the time, it was often not included).
I outlined a method (Ghostscript to the rescue) which would reduce the requirements for all the printers to the bare-minimum of PCL3, assured them that while the forms wouldn't look identical to what they gave us that they would be close, and still have final approval.
Now, I don't consider any of the above a big deal.
At the end of the meeting the IT Directory says thanks to everyone and then apologized to me, and the company I work for.
He said he spent the last 15 minutes telling his staff how incompetent we were and incapable of handling this project and maybe they should cancel the whole thing and look elsewhere.
When we left the Manager who came with me thanked me for saving the project.
I honestly think the IT Directory was so used to dealing with consulting companies that were trying to rip him off and make things sound more difficult than they are he simply decided we were lying to them so we could jack up the number of hours, or the rates for parts of the project.
And that comes from having managers act like what you described. Padding development time so they can look good, keep the expectations low (no additional features without begging for them), etc. Long term that breeds an adversarial attitude.
Abortions for some. Tiny American flags for others.
pooptruck
You can't make everyone happy.
Use hierarchy to your benefit: If upper people make decisions, they are responsible. Make a written document detailling why you cannot reach all three goals. Make THEM decide what to do. If something fails and they want to blame you, pull out your document.
This is called "Cover Your Ass".
I've been lucky, most of the time I work with the customer directly, they have far more work than I can ever get done so things are simply prioritized and I do what's next on the list. I don't have to worry about a Manager demanding a different estimate from me than what I would say to the next person in the chain.
:)
Ah, but usually it's not that simple, someone has to bridge the gap between engineers or techies, and management or marketing. After reading all these comments here, I'm starting to suspect those are the persons worth their weight in gold. The famous missing link of the IT world!
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
Are you saying that it's okay to purposefully take longer on a project so that a customer will have to pay more for it? It's one thing to say that giving a deadline to a customer is a bad idea because you can't assume that the company will only have you work on his project for the next few months. However, if a manager wants you to purposefully attempt to "drag out" a project just to make the customer pay for more hours, I kind of feel like that's crossing a line. If the customer is paying you on a per-hour basis, rather than a per-project basis, and you set out to trick him into paying you for hours you didn't spend working on his project, then I see that as fraud. But maybe I'm misinterpreting what you're saying (I hope I am).
No, it's a question of sales tactics. Suppose
Now is it unethical to push the shinier, spiffier product on the client?Is it unethical for a car salesman to say, "Yeah, that Chevette is a nice little car, but come over here and get a load of this El Dorado Brougham"?
Is it unethical to make sure that you're sufficiently profitable to pay the rent, and the heating bill, and the food bill, and the prescription drug bill, etc, etc, etc???
Is to help you understand the real-world constraints you are operating under, and then protect you from being further bothered by senior management. It sounds like he is not doing either one.
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
To paraphrase Arnie in some film where he plays a russian cop:
"Vodka!"
That's guaranteed to make Mr. Knows very angry with you, since you're making him look incompetent in front of Mr. Weed.
What you actually do is talk to Mr. Knows in person and say, "Brown, there's a conflict between what you're telling me and what Dick is telling me. Please sort it out with him so that we can all be sucessful." You then follow up with Mr. Knows every day (or hour, if necessary) until he resolves the conflict.
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
- Have a good estimation template, guidelines for estimate, documentation to say how estimate is reached at. Explain the estimation procedure to management and get their approval. First cut of estimate can be based on previous experience and promise management that estimation figures will be improves by periodic analysis.
- Insist on estimating all developments upfront (this will require clear requirements upfront). While giving estimates, list the assumptions and features considered. Put in a disclaimer that any change to above will require a change in estimate.
- Implment a change tracker to show to management how many changes came in during development. Estimate the changes and appraise management periodically about changes. Insist on freezing requirement/design at a stage after which change will be more costly.
- Create a schedule based on estimate and publish the progress. Let the management know as soon you encounter any critical issue which may derail the schedule.
This kills agility of development and sometimes breeds lack of trust between users and IT. But putting it into a rigid framework of process reduces chances for others to blame you.
You can't please everyone all the time. Simply can't be done. So, just give up on that notion right now... someone is going to be disappointed no matter how well you do or how hard you try. It sucks, but it's inevitable in the same way gravity is.
:-)
With that out of the way, let me give you some practical suggestions. I'm not a programmer, but I used to be a production drafter for a manufacturing firm... same issues, different field.
You describe an organizational hierarchy. This structure causes you problems when "upper management" tries to interfere, but it also should protect you somewhat from such interference. Part of your boss's job is to shield you from unnecessary interference from above. This is a difficult responsibility of his, and maybe an impossible one... you need to both let him know that you expect him to accomplish it (or at least try harder) and offer him whatever help you can.
The best way to do this, IMHO, is to go to him and tell him about what you're seeing and hearing. Tell him that you're getting messages from certain specific members of upper management that conflict with the directions he has given you. Tell him that you'll be delighted to do whatever the company would like you to do, but you would very much appreciate the company making up its gorram mind about just what it wants from you. Ask him what he would like you to do about mixed messages from above.
This approach lets him know that there is a problem, that you want to be a team player, that you want to follow his lead, and that you are expecting more from him than he is currently delivering. Delivery of this message needs to polite and focused on finding solutions.
Your boss is a necessary ally. If nothing else, keep in mind that he writes your reviews.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
he needs to become a consultant.
That way he can tell everyone..."no matter what you want I need you to make a decision. Meanwhile I'll be over in the cubical with the crappy chair and no lights collecting my $150 an hour....wahahahahahahahah"
6. Blow yourself up in a train full of people.
Ahem, for the record, at the session with the client my manager turned to me and asked me how long I thought it would take. That was when I gave my "estimate".
That makes a very big difference. Your manager is an idiot, though you gave the impression the first time around that the estimate was unsolicited. I love when guys on my staff come up with ways to do things better or to fix problems we've been having. I hate it when they throw in things without talking to me first. I have a very different perspective on things than they do, and have my reasons for making my decisions.
The company I work for survives only by the level of customer service that we provide, and the key to that more than anything else is communication. I don't want control for control's sake, I want control because the road to hell is paved with good intentions.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
Hello mooingyak
First, I need to (and wish I could somehow propogate this better) for the record emphasize and clarify my excellent relationship with my manager. We both gave as good as we got from each other and respected each other. He gladly and without prompting rewarded me for good work done well many times. But this was a case, as you pointed out, where his job was to make sure corporate procedure and policy prevailed. I still think he was harsh, and maybe even a little wrong on this one, but he was (and to this day is) a good guy and did try to do the right thing.
To your other point, I agree, excellent point that it has got to drive a manager crazy when an employee sets off on his own, doing "extra" work. In this situation, (and I was considered a manager, technically, and expected to show appropriate behavior) the extra work needed to correct the "other" problem was less work and time than it would have taken to go through any process.... unilateral on my part, but NONE of my tasks or responsibilities were compromised... AND (I think I mentioned this in one of my posts) I ensured my deliverable was the deliverable they expected with the option of considering the other fix (which is why I forked the code... to allow for either choice, with no contamination to the original work).
The final result was a much better relationship with the clients.
Ultimately, your points are correct and well made. My disappointment was what at the time felt like excessive pedantry and strict policy adherence.
Best Regards... yagu
A blowjob goes a long way.
7. Profit!
I can say is that if that type of thing is a preferred standard American business practice, then it's no wonder that our country is going down the toilet.
No shit. If yagu's boss won't go the extra mile for the customer, he can damned well bet that Sivaramachandrahoosis's boss in Mumbai will. Based on what yagu has posted, especially his clarification that his estimate was actually requested in front of the customer, I'd hire him/(her?) in a minute and trust him to lock up the office at night.
That manager shouldn't be entrusted with anything more strategic than estimating how many drums of synthetic trans-fat compound the Fryolator will consume next month.
Ooh! Some random terminology fresh from the blender... =)
Time for a friendly game of pick-apart-the-post.
> You're an engineer.
Sorry to stop so soon, but you've inferred out of nowhere that this guy is an engineer, and since we're not talking about making toasters, a software engineer. So you should probably know that the distinguishing feature of software engineers is that they concentrate on delivering quality software on time and under budget that fulfills the customers needs (i.e. the responsibilities of a software engineer) first, and the other interests of their employer second. Was that what you meant?
> You don't deal with customers on anything other than the purely technical level.
The usual view is that technical decisions on a project are the responsibility of the development team. So, other than finding out if the customer has any technical requirements (because of technologies the customer is already using), developers don't talk to customers about technical issues. They talk to them about functionality (i.e. non-technical requirements). That's the opposite of what you're saying.
> What you were doing --- making estimates, adding functionality --- was making business decisions.
That sentence makes so little sense I'm not even sure whose "business decisions" you're talking about. Making estimates doesn't involve decisions, it involves using the available information to make an educated guess how long something will take. And adding functionality involves making technical decisions, but not business ones.
Obviously adding functionality is what the programmers were hired for in the first place. And programmers should be in a position to make estimates about how long tasks will take them (as it is usually their responsibility). Nothing out of line there.
>You got away with it this time but you were running the risk of seriously screwing up any business relationships your company was participating in.
Do you just mean that the company isn't making as much off a customer during a particular project as it could be?
Delivering the customer minimal services at maximum prices is the key to many things, but a sustainable customer relationship is not one of them: The company keep having to abandon its customers when they a) catch on and demand lower prices or b) go bankrupt due to their own stupidity.
>For example, in the business with the estimate, what would have happened had the customer insisted on going by your estimate and not your manager's (doubled) estimate? At a stroke you would have halved the company's billable hours. Not good.
On the other hand, if the double estimate was too high, and the company had started by giving the customer that? The customer would have said "no thanks", and gone somewhere else. And then, the company doesn't get to bill for any hours, fraudulent or otherwise.
Basically, the way that manager is operating, they better hope that there are so many patsies that competition will never be an issue.
>The only way they could have gotten out of that is by telling the customer that you'd spoken out of turn, which would probably have led to you being told to find another job.
In which case, good riddance, and the guy would have a great contact to take to his new job.
>First rule of dealing with customers: find out exactly what your responsibility is, and don't overstep it. If the customer asks about a new feature, say, "That sounds feasible, but of course I'll have to run it by X first," where X is your business contact. Or even better, say, "You'll have to talk to X about that, I'm afraid." This is the kind of thing management is for; use it...
With that approach, the business contact always has to make the decision, even when they don't have the information to make it properly.
I'm glad you recognized that my points were mostly generic and not necessarily specific to your case. At this stage I just want to know how come you keep getting modded up and I don't :)
Also good to know that your manager is not a total moron, just a guy who probably made a bad call once. I know I've made some less than brilliant moves on occaision.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
Yes, doing our jobs and letting the managers do theirs is certainly causing our country to go down the toilet.
Idiot.
It is not the programmer who must make others happy, it is he who must find happiness within others for without their happiness, he will not know himself.
-- Game Developers: Stop porting badly-textured games from crappy console systems!
When you're in a consulting firm you have to serve two masters. Sometimes it can really suck, especially if you're the type of person who is client focused. My advice is to become either an employee of their IT department, or better yet, an independent consultant and work directly for the clients you want to work with. Don't let any manager get in your way, you talk to and work directly with the end business client. The client, if high enough in the organization (VP, etc) will protect you even if a dumb manager does try to get in between you and the client. By the way, keep that client's phone number, and the next time you need a job, or want to start contracting on your own, give them a call. The IT industry needs more people like you; you obviously build trust. I think you can see everyone else's "duck and cover" attitude, and extrapolate as to why the industry is in trouble.
Tristan Yates
The problem of software quality for commercial software boils down to this.
In a market where some schmuck (developer or more likely, executive) is always willing to do
an undocumented spaghetti, one-off solution, for less and quicker, and where most customers
don't know the difference, good internal-quality, maintainable, extensible software is too
expensive to build and sell.
The customer will lose in the long run, when they find that the software is not upgradeable
or maintainable. If the software vendor is trying to make a living off releasing upgraded
versions of their product, they'll lose out too, eventually, but the manager of the original
project will not be blamed. They will be the CEO by that time, rewarded for the short-term
profits they produced by whipping the developers in the original project.
The trouble is, EVERYONE, in the commercial market, heavily discounts the future. Nobody
minds creating a long-term problem if doing so will "apparently" solve a short term problem.
What this all leads to is a market where the market CANNOT AFFORD the prroduction of
quality software. Developers of good instincts, skills and conscience (who are loathe to create
bad, unmaintainable, special-case code) are pretty much guaranteed to suffer in this
environment.
It would be nice to believe that there are some software companies that are led by
long-term-thinking management with a true technical clue. Management truly interested
in developing software capital; software of such quality and simple elegance that its intrinsic
value (and eventually, its market value) grows geometrically as it builds on itself, rather than
declining as it builds cancers onto itself, as is usually the case.
Does anyone have a tale of such a holy grail of a software company?
Where are we going and why are we in a handbasket?