|
Just curious. I've seen so many promising products release to a big fanfare and rave customer reviews that (not too much) later are rotting on the vine because fixing bugs and adding unforeseen features are nearly impossible.
Dale Thompson
|
|
|
|
|
"The job is fully documented
The design and implementation was first rate"
Those go some way towards maintainability, right?
regards,
Paul Watson
Ireland & South Africa
Andy Brummer wrote: Watson's law:
As an online discussion of cars grows longer, the probability of a comparison involving the Bugatti Veyron approaches one.
|
|
|
|
|
Maintainability is WITHOUT A DOUBT covered in Design and implementation.
Mike Tsouris
Developer
http://tsouris.net
michael@tsouris.net
|
|
|
|
|
Sure - someone is paying me to make something for them.
But, the reason I'm in this business is because I love coding.
It's no different than a painter or composer;
Or a chemist or physicist.
I hope I include most of you when I say this is our art.
A fine piece of work - a clever routine or an imaginative solution: because we are more and better than an a cooks following recipies on a boxes.
That our work wasn't merely done by the book - but beyond it.
Why else do this for money?
"You sell all your hours for a handful of dimes . . ." - Jimi Hendrix
|
|
|
|
|
I agree. What we do is an art and we all take pride in it......
BUT. DO NOT FORGET that....
Oracle costs a crap load of money
SQL Server licenses costs a crap load of money
WINDOWS SERVER costs a crap load of money
20 licenses of VISUAL STUDIO 2005 for your development team costs a crap load of money
Where does that money come from?
The business. We code for money FIRST. Just like musicians and artists who work for commissions, we all have to set aside our own preferences when we are doing this as a professional gig.
I love a beautiful architecture as much as the next senior programmer, BUT, money talks, and there are many times when we have to PURPOSEFULLY make a piss poor sh*t design because that is what fits in budget and time line.
good programmers know how to make it work inside these real world parameters.
THE MOST IMPORTANT PART OF ALL THIS IS DELIVERY.
Bugs can be fixed and are considered acceptable in our culture.
Look at the .NET Framework..... Have you ever profiled "hello world" in a .NET app? It uses like 20mb of memory! But who cares, because the point is rapid delivery of working applications.
Optimization and beautiful architecture is a LUXURY.
Mike Tsouris
Developer
http://tsouris.net
michael@tsouris.net
|
|
|
|
|
I thought the money part was implicit in "Sure - someone is paying me to make something for them."
One of those things that seems clear to the writer and not quite so to the reader. Perhaps I was feeling too much the poet?
The whole thing does revolve around the money. I make them pay me, too.
For that matter, sex really revolves around reproduction. That works, if that's all one cares to make of it. Whore's do it purely for money; and lovers for the unequaled beauty of the shared expression. You can fill in the in-between mitigations as you wish.
I'm not unaware of the cost of things - I just like to pretend to myself they're of no importance, taking pleasure in the plan while it yet unfolds, as though it were alive.
"Life is just a bowl of all-bran.
You wake up in the morning and it's there."
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
|
|
|
|
|
I agree for the most part.
The one thing though, is, the fact that one can put a lot of stress on themselves in the daily grind if they put priority on the finer things of programming.
Take for instance, a scenario where a project's deadline and resources don't really accommodate for the best architecture. If you find yourself caught up in the "preferred" approach, ie. making the most extendable and elegant architecture possible, you can basically doom the project yourself from day one, by not realizing that it's only a job, and you just have to make something that works.
The sales manager will NEVER pat you on the back by adding built-in support for interoporability for older platforms or using reflection for dynamic greatness..... they just want to see it work. You'll get a promotion MUCH faster by making a reputation of always delivering. It's amazing how forgiving people can be of "bugs".
I am not criticizing your comment, it just reminded me of how I Personally used to approach things (the most ideal way) and how, after several months of 70 hour work weeks, i realized to detach my personal investment of pride from the actual project.
I'm not saying do a sh**ty job all the time, just try to find that balance between ART and DELIVERY.
Mike Tsouris
Developer
http://tsouris.net
michael@tsouris.net
|
|
|
|
|
|
I can not agree more!
That is how I have always felt about coding. Good code is an art form and a thing of great beauty. It makes it easier to maintain and understand. Due to time constraints, or other reasons, I have not always been able to create great art, but I do try.
At one point in my career I had nightmares about the code I inherited. I am not sure if I would have taken him under my wing or requested that he be fired. I know the true meaning of spaghetti code and have learned how to straighten out some amazing messes.
My favorite analogy has always been that of an author creating story: research, outline, write, and rewrite; with attention to detail. You do not design your character by placing his head in one place and his arms, legs, and body in a dozen others.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
The programmer, manager, CEO/stock holder and client/customer will all have different priorities.
Hence the conflicts we have in any development effort.
Marc
|
|
|
|
|
Having a good PM to run interference between development and clients takes some of these conflicts away, or at lest pushes them further away.
only two letters away from being an asset
|
|
|
|
|
in software development, it is quite common that the budget is an amount of working hours; the longer the developers spend on a project, the more the project will cost. I would be surprised to see the two values differ too much.
just my two cents
Federico
|
|
|
|
|
Federico Sasso wrote: in software development, it is quite common that the budget is an amount of working hours; the longer the developers spend on a project, the more the project will cost.
Not necessarily. The client may say they need the project completed in three months (by the calenday) but only want to pay for 6 man-months of development effort despite the fact that in order to get it in on time it will take 3 people (i.e. 9 man-months)
So, they are going to have to trade off something.
|
|
|
|
|
Hi Colin. Thanks for your comment. I'm not so sure I get your point, who is "they"? Do you mean developer and client?
I realized that there's a potential ambiguity in my statement.
I'm talking from a developer company standpoint: when I say "cost of the project", I do not mean how much the client will pay for it, but how much it will cost to the software house to develop it.
Once a contract has been signed with a fixed price (and may be penalties for late delivery) and release date, the software company allocates the resources to make it on time; suppose now that problems arise, two things can happen: release date is delayed, and in this case running out of time means running out of budget, because even without penalties, I still have my developers working on an old project and cannot apply to a new one, so the company income lessens but we have to pay the developers the same; or, we have to inject new human resources to make it on time, so that also in this case development cost arises, since the newly added developers could otherwise work on something new.
Project scheduling tastes so much diffent when you're the one paying the bills... (I'm still am not the one, btw 
Federico
|
|
|
|
|
In my more than thirty years of programming every place I have worked, time was the biggest factor. The old saw there is never enough time to do it right, but always time to do it over seems always to apply.
When prediction serves as polemic, it nearly always fails. Our prefrontal lobes can probe the future only when they aren’t leashed by dogma. The worst enemy of agile anticipation is our human propensity for comfy self-delusion. David Brin
Buddha Dave
|
|
|
|
|
David Lane wrote: time was the biggest factor
Indeed. A while back, the company I work for brought in one of these 'touchy-feely' management consultants to find out why the engineers were so disgruntled. One of the complaints was that our schedules are dictated from above.
A typical schedule discussion goes something like this:
Management: "We need features X, Y, and Z by the end of Q1 next year. What's the schedule for that?"
Engineering: "Uhh..."
Software Zen: delete this;
|
|
|
|
|
Sometimes it becomes necessary to add manpower to meet schedule. The project can come in on time (end date met) but be way over budget because of unplanned staffing.
|
|
|
|
|
In my last job they developed the project to a budget.
The time I worked on the job multiplied by my hourly rate was counted in the project cost. So, I was under pressure to finish quickly and it wasn't quite done to the quality that I would like.
There was free time at the end to improve my module, but they wouldn't let me because the extra time spent would bust the budget. And I had no other work to do once the project was finished. I'm a saleried worker, they pay me weither I'm working or just hanging out on the forums .
Really smart project management
|
|
|
|
|
I think the following ( 1 is most important)
1. The design and implementation was first rate
2. The job is fully documented
3. The client / boss etc is happy (although some people never are)
4. The job is done within budget
5. The job is done on time (although, it will take as long as it takes to satisfy 1)
6. The job matches the initial specs perfectly (very rarely happens)
7. The job is done error-free (there has never been a project of any import which works on version 1.0.0.0)
|
|
|
|
|
How long have you been in the industry?
"3. The client / boss etc is happy" is number one. It shouldn't be but it is.
regards,
Paul Watson
Ireland & South Africa
Andy Brummer wrote: Watson's law:
As an online discussion of cars grows longer, the probability of a comparison involving the Bugatti Veyron approaches one.
|
|
|
|
|
'On Budget' should be higher surely if you want to make a living...
Apathy Rules - I suppose...
|
|
|
|
|
Client won't pay if they aren't happy 
And it depends how you charged. We never go on fixed price.
regards,
Paul Watson
Ireland & South Africa
Andy Brummer wrote: Watson's law:
As an online discussion of cars grows longer, the probability of a comparison involving the Bugatti Veyron approaches one.
|
|
|
|
|
Since you're developing iteratively (you are, aren't you), you're reviewing the project every 2-4 weeks. If the business call is that greater investment will bring sufficiently greater returns to justify it, or if by keeping to the budget you'll not actually have anything that customers will buy, or if you have to meet a deadline and missing it will nullify the project (think Olympics, for example) and you can pull it in by increasing investment, going over budget is fully justified.
It does, of course, need to be a calculated decision with the business case to back it up.
Ian Brockbank
"Legacy systems are systems that are not protected with a suite of tests. ... You are building legacy code every time you build software without associated tests." - Mary and Tom Poppendieck, Implementing Lean Software Development.
|
|
|
|
|
Paul Watson wrote: The client / boss etc is happy" is number one. It shouldn't be but it is.
Unless you're an academic researcher, you're developing software for a paying customer. If that customer isn't happy when the job is done, none of the other considerations matter. I don't see the problem with that being the primary consideration, especially since it encompasses the other entries.
Interestingly, all of the other items reflect the developer's esthetic regarding the job, his criteria for success. They can contribute to the 'customer being happy', since he may define his requirements in those terms. "I've got to have this by the end of the month", "I can only budget $20K for this effort", "I don't care how many features you give me, but what you do supply has to be rock-solid", and so on.
I think if more us spent more time on accurately identifying what the customer really needed and then meeting that need, the software industry would have a much better reputation. It's like the old joke: "You start coding; I'll go see what they want." 
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: I don't see the problem with that being the primary consideration
Because you can make a client happy with a badly architected system.
regards,
Paul Watson
Ireland & South Africa
Andy Brummer wrote: Watson's law:
As an online discussion of cars grows longer, the probability of a comparison involving the Bugatti Veyron approaches one.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
