- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
stupid community server
Admin
I know exactly what you are talking about. We used to use it before the invention of the GPO. The entire damn thing can be summed up in the word: FAIL.
/me Goes to open the GPMC
Admin
It's stuff like this that makes me so glad I work where I do. The VP of development, who's an experienced coder, sits in on the feature request meetings from clients and prospective clients to keep things sane. He has a hand in writing the requirements documents, up to and including executive veto power over anything that just won't work or can't be delivered on schedule.
(Second post attempt)
Admin
I get it, the method name in the SQL Sentences story should have been GetSqlSentences() instead GetSQLSentences()
Admin
Admin
Admin
That's a federal standard now, FIPS 181.
Admin
Years ago, my boss at the time asked me how long it would take to write a program to perform some task. I don't remember what it was, but it was pretty complicated the way he laid it out.
I told him 2-4 weeks. He said he'd let me know.
The next day he said to go ahead and do it. I answered that I already finished it.
The night before I got to thinking about it and figured out that I could do what he wanted, but not in the way he wanted me to do it, with about 30 minutes of work. So I went ahead and did it.
Two weeks later, he walked into the VP's office and announced that we had got it done exactly on schedule.
Admin
Admin
[It should take 5 minutes to implement a feature that tracks info from before the app was installed? Ok, here's what I finished in 5 minutes. You may notice that it doesn't do anything, but we'll take care of that in a previous version. ]
pwned. I may adopt this method.
Admin
...but he gets commission on the $10k, not the $100k. Better to make the sale...
Admin
I don't work at a software company, but I do work with sales people, so this is all too familiar. If the customer demands it, more than likely we'll do it, even if it requires violating the laws of thermodynamics and destroying the fabric of the space-time continuum to do it.
/weapons at maximum!
Admin
A good developer will either not pad or will create flexibility that is never used (making them not so good). A great developer will create flexibliity that is nearly heroic in the future. Usually I stick with the idea of planned refactoring. But when I have seen planned adaptability done right it is usually due to a single great programmer after a huge battle with a bunch of good programmers.
The simple reality is that many successful projects get a financial momentum that is suicidal to stop and refactor.
If you study the battles of the greatest generals in history they almost always held back a reserve part of their army. If the battle went well those soldiers never entered the fray. But the moment a hole formed the reserve was sent in. One would think it would be smarter to have 100% of your men in battle. The mathematics look good on the surface. But the reality is that you don't beat a whole army you just poke a hole in it and then exploit the chaos that results. The same goes with a product launch. Once you have your troops in battle (your product) you can't pull it back and spend 6 months retooling it. You need to be able to adapt to a changing market while keeping your code in the fray. Thus you should launch your product with some reserve functionality that can handle the simple fact that it is absolutely impossible to product the exact right product. Now none of the above applies if all you are doing is a contract making crap internal software that only has to be contractually correct. Where a great programmer comes in is that they will identify (from experience) the most probable flexibility needed.
i.e. If this web based product really takes off we will need to design the product to move to a clustered environment quickly.
In the above example I can't imagine refactoring code from a single machine design to a clustered design in the panic of an overloaded server that has already had some powerful hardware tossed at it. What I can imagine is that you would move to a cluster with your cluster ready code and then do some minor tweaks to better exploit the cluster. Thus avoiding a cluster-f...
Admin
And that, Ike, is the reason I hope I never hire you.
Admin
Now I just code what I need - I can still refactor later...
Admin
Kudos. I'm so happy that a company like the one were you work actually exists. I was beginning to lose faith.
Admin
There is a need to deliver things on budget and not waste heaps of time on buliding 'maximum flexability' features in your code or architecture design. But you can certainly benefit from adding in a few common features in your database architecture to help speed up building of future customer requiements (and it doesn't add to much build time).
1)A Visible or 'Is Online' boolean field 2)Making certain kinds of relationships Associative Tables (1 to Many) instead of just straight out Foreign Keys (1 to 1). 3)Include Date Ranges for Visability/Avalability of Items. 4)Include a Sort Order field (for an OrderBy Clause). 5)Include 'Select A' Options in a Database Table with Foreign Key Relationships rather than just 'Hard Code' the values in the page.
While these types of fields/features aren't always required there is certainly a good case for including at least some of them in a lot of cases. I don't know how many times I've been saved a lot of development time and pain down the line by having the foresight to include this functionality in my system design, even if it wasn't required straight away.
Admin
After reading the article and all the comments up to now, I learned an important lesson: If you are responsible for personell or even the boss, no matter what happens, do NOT entrust sales people with any SALES RELATED work!
Admin
Like many others, this company sounds like one I used to work for. I never understood why salespeople weren't paid commission on the profit of a sale, not the price tag.
Admin
Admin
Admin
Wow, that page is a really brillant diamond!
Clicking on download with Javascript disabled gives an error message:
However clicking on download with Javascript enabled results in an error message displayed in a modal dialog which will not go away but be displayed in an endless loop again and again.. (At least it is telling the reason: "Cookies disabled". What did you smart people at foolproofsoftware / Horizon DataSya expect from people who are concerned that "thier personal information on thier system is easily viewed by anyone").
This company must be filed under chapter 11. The sooner the better!
Admin
I love the URL you get after you open foolproofsoftware.com and click on Company: http://www.horizondatasys.com/169561.ihtml?__utma=1.892241361.1255519800.1255519800.1255519800.1&__utmb=1.2.10.1255519800&__utmc=1&__utmx=-&__utmz=1.1255519800.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)&__utmv=-&__utmk=162712764
Admin
They exist because sales brings in revenue, even without a product... for a while.
Admin
Admin
OK - I was wrong - seems there is a convention (or at least a "MS bull") on the subject. http://msdn.microsoft.com/en-us/library/ms229043.aspx http://blogs.msdn.com/brada/archive/2004/02/03/67024.aspx
Admin
Anyway, you tell him to deliver the product then...
Admin
Admin
The solution if you want to incentivize your salespeople properly is to give them their cut from the bottom line of the deal instead of the top line. In a deal that costs the company more than it earns, they then have to make up that difference with net positive deals before they can receive any sort of commission.
Like with mortgages, if salespeople get bonuses for sales which will ruin the company, they will make those sales.
Admin
Admin
I worked for a small company like this. The owner was the sales guy... He'd meet with ANYONE, and he'd promise whatever they wanted...
We had a cash flow problem once too... He said he couldn't pay us programmers for a week... We (all 3 of us) said "we'll be back in a week"
He found the money to pay us that day...
Admin
Admin
Humm? I'm sorry, but I'm new here. Are you trying to tell me that was a true story? WTF!
Admin
"Interestingly enough, fixing bugs was nowhere to be seen in this policy."
So there's your solution. When asked for an impossible feature, you do nothing, but ship the existing product. When the customer complains that it doesn't work, you log it as a bug.
Sheesh! Kids these days, they have no idea...
Admin
This reminds me of an anecdote how the business is done in the ex-USSR pretty much since 1991.
Businessman A meets Businessman B. “I have a few tons of sugar to sell,” tells A, ”and I want $1,000,000 for them.“
“Sounds like a good deal to me,” tells B. They sign all the agreements and go their separate ways: A has three weeks to find and deliver the sugar, and B has to find a million dollars of payment in three weeks.
It almost inevitably happens that by the deadline, a party still has hard time with deliverables. The other party usually too has nothing to show, but this is a wait game in which whoever admitted to the fault first is the loser who then gets his ass sued all over.
Admin
Admin
My favorite sales story was the sales person who told a client that one of our developers had been a key developer on the package they wanted us to use. None of us were even sure what exactly the product was or did let alone been a key developer of this product. The horrible thing was that after a week of cramming we knew more about the product than the clients in house developers who had actually been using the product for years.
Admin
Now, normally you'ld think the "go back to step 1" bit would first require you paying back all the people you screwed, but that's what the lawyers in step 3 were taking care of for you.
For extra points, "sell" the name and assets of the company to yourself, and start a "new" (heh, heh) business with the same name in the same industry and with the same employees, and all the liabilities are left with the old business.
Yeah. I love business.
Admin
Admin
The WTF here is not what your boss did, but that seem to think that he did the wrong thing. Do you think you'd have been the "hero" for getting it done so quickly? Not exactly. Let's think about what really happened here:
Let's think about what would have happened if your boss had told the VP that you'd finished a project approved for two weeks in one day:
Better to meet the expectations that have already been set. The VP is happy that the code was delivered on time, your boss is happy that he met expectations and got still got extra productivity out of you for those two weeks. Everyone looks good.
Your boss will probably forget that you made a terrible estimate because no one complained about it, but remember the extra productivity. So, even though it doesn't feel like a win for you, you're really better off; that is, unless you and your boss hate each other and really you need to impress the VP.
Admin
The problem with trying to make something foolproof is that fools are so creative.
Admin
The key thing is balance. No, you shouldn't strive for the ultimate in flexibility and generically, but neither should your code consist of a big lump of spaghetti.
Both are wrong and both are evil. When a simple accounting application starts using the identifier "Thing" instead of "Account", because of the idea that one day you might need to track other things than accounts, you're most obviously wrong. On the other hand, if the entire application consists of one huge class with methods randomly manipulating 'well known' indices in some array that represents all domain entities (as in entity[20] is account.name), then you're obviously being quite wrong too.
The well educated, smart and experienced developer creates an architecture that represents the current requirements well, but anticipates for future change in a reasonable way, mostly by sticking to well proven patterns and sensible setups.
Simply NOT putting your core business logic between the TR and TD tag in some obscure .jsp page or within the onClick handler on some VB dialog, is already a huge step in the right direction.
Some sensible choice made at the start of a project, costing you the proverbial 5 hours, don't just have a 10% chance of saving you 5 hours later, they have a 100% chance of saving you months and months of time later.
I'm currently refactoring such an application. Just because at the beginning no simple rules were established for doing CRUD operations, EVERY single piece of code is doing it differently, with different names, different ways of starting and committing transactions (if they use it at all), different ways of encoding values for inclusion in SQL (some use URLEncode, some use XMLEscape, and some use the only reasonable thing: prepared statements).
Due to NOT taking the time upfront to establish this, NO code can interoperate with each other now. Want to join the orders with the inventory based on keyword? Bad luck, since one of those tables URLEncoded all values, while the other didn't and there is no url decode function in the DB. Want to save an order to the DB and in the same transaction deduct the inventory? Bad luck again... the code for saving the order starts its own transaction internally and that one can't be nested with any other ongoing transaction.
The list of such things is endless. It has already taking me many months to align all this stuff, which is utterly necessary but could have been easily prevented. It's not that a few years back DAO patterns and MVC designs weren't know to mankind...
Admin
This is the exact situation when you might have used a plug-in based system.
Admin
With a crack sales staff like that, the company should have been able to convince the customer that browser history was all they needed.
/sarcasm
Admin
I tried to change my password to "password" but the database objected with some gobbledegook about a Primary Key Constraint Violation.
Admin
Only if the aforementioned plug-in based system is designed correctly and in the simplest/most effective way possible. It sounds like an oxymoron to state what should be a self-evident truth. But I've seen enough over-engineered/over-architected plug-in based systems to know that is one thing architect/developer astronauts get very wrong.
Admin
Wrong. You do that only when you have a terrible job with terrible management, and you have every reason to use that as a scheduling defense.
IMO, Eric should have never told his boss that he got it done over night. Unless he knows and trust his boss very well, that's a risk - it might set up a precedence that things can be done "overnight" (I've seen it happened.)
A better approach - assuming the boss is not an as*ole - would have been to talk with his boss and present an alternate solution (which he know by prototyping that it works.) The alternate approach is presented and discussed with the suggestion that it can be done quickly.
It helps create a rapport of trust and communication. It helps the boss understand how the developer comes to the alternate solution, and it might help the developer understand why the boss presented his solution the way it did (and perhaps uncover other things that might need to be implemented.)
This also gives a safety buffer in case the developer ends up assuming the wrong things (it's always possible.)
You never present everything done immediately. You always give yourself a buffer (for error detection, negotiation, whatever.)
But you certainly never, if you wish to be an honest engineer, you never take up the three full weeks and claim it took you that much time to do X work if in reality it only took you a day or two.
If you are the boss, you might have to (after all, a boss might be working on multiple projects and all that crap.) As a developer, that might shoot you in the foot. As a developer, you are in charge of less deliverables, and you have to justify at some point why X or Y took so long.
You are either a manager or a developer. Don't try acting as both (or worse, assume that a boss' role is to always lie about schedules and then take that false role as if it were yours.)
Admin
Oh this story is so familiar to so many small companies it isn't scary anymore but almost a fact of life when non-technical C class employees run the company solely bye the bfl and next mega sale.
It is even scarier because at a point C level Mgmt could not determine where the Software Development VP should report to. Surely not the CEO, or the COO but instead to the Customer Service VP. So after 16 years of a successful track record confusion became the norm because Custom proposals now used the SWAG method to quote $ and time. The idea of resource leveling and other key principles previously established now were trashed because they were written for the development process with checks and balances.
Worst became the proposals including technical commitment and overview never made it to development until after deal was committed to. The attitude is the development was bust so we can help them by reviewing and approving custom development requirements good bad or indifferent.
So now a team that had been and still is committed to deliver projects on time have to deal with coitus( oops code) interruptions causing delays by C level Mgmt that would not listen to technical details.
So BFL is what drives all coding and most info given to development was such a gaggle of words with no apparent connections the road to a greener world opened wide and 40 % of the development team is now in greener pastures and the developers who are still around will be gone in less than a year. They want to work in an environment that is based on sound principles and practice not lattest quim or next coitus(darn I did it again) interruption.
It took 5 years to build a solid team. It has taken far less to kill it because of management not listening to department head that was responsible for development. The dept head and developers all need to move on. R&D is not important just the last proposal. Each day is a new custom.
Admin
Litigation Driven Development