|
In one case, I was sent to a customer site in England for ten days to test a special modification we'd made for them. It was supposed to work in conjunction with some additional equipment from another manufacturer, which we'd never seen and had only receive a single specification from.
I spent the ten days standing around while the other manufacturer tried to get their *cough* prototype *cough* working.
Software Zen: delete this;
|
|
|
|
|
Even I spent a day or two to a client place couple of times for printers. Got issues like drivers failed or invalid version. It was thermal printer. we tested our code with one printer which was given by printer guys. But later we found some other printer which didn't work properly, we got print with improper format which was really useless.
Most terrible thing is Client called us for printer related issues. One time my collegue told me that they called him to solve an issue. But he found that they didn't on the printer. After that, we usually told clients to print a test page to redirect them to printer guys.
After these things I hated to work on hardware things like printer, barcode scanner/printer, etc., 
|
|
|
|
|
Gary Wheeler wrote: I've worked on special versions of products for customers where we didn't even see the hardware until it was time to deliver the machine.
Pfft! Try programming conveyors that can't be completely programmed until they are built and once they are built the client thinks they should be able to immediately use them because they are built.
Lots and lots of 36 hours days during that phase of my career.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
As an occassional app developer for both Android and iOS the nightmare is always having to grapple with the kafkaesque labyrinth that is Apple's publication process. Even if I simply want to deploy an app directly to our own fleet of iPads it is completely obscure. The Android situation is better but not much.
It is probably fine if you are frequently doing mobile app projects and tageting the mass market so want your stuff to appear in the App Stores, but for in-house custom development it is awful.
RogerCO
|
|
|
|
|
Most product managers are clueless and their specs are full of gaping illogical usability holes! Asking dev to add features which makes no sense to the customers.
|
|
|
|
|
I found the most hardest bit is the specifications provided by the client, which is always volatile. This happens in more than 95% of the cases. In worse scenario, it happens unpredictably and changes the whole stuff finished so far.
However, I guess this is the nature.
|
|
|
|
|
Swinkaran wrote: I found the most hardest bit is the specifications provided by the client
My experience has been the specs provided by the salesperson. They always leave off features they promised the client but failed to make any record of what they promised.
I had one time we were working long hours to complete the code for this conveyor and three weeks into the project and at the end of a 24 hour day the plant manager starts talking about this feature he's looking forward to that my programming buddy and myself are wondering what drugs he was on (or wondering if we needed to be on some) to later find this major portion of the specs was completely missing and the deadline was a week away on what we estimated was going to be a two week effort to add the missing feature. We didn't even have the hardware to implement the feature, let alone program.
That was just one of many "Oops" by sales.
But yes, we had some where the client asked for something that had no chance of working the way they thought it would.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
the missing option is EVERYTHING.
App development is a pain compared to desktop... or even server.
|
|
|
|
|
What about desktop apps?
Software Zen: delete this;
|
|
|
|
|
Desktop apps are ease provided you're not trying to make them with a "blahML" (HTML, XAML, etc) interface. It's been several years now, and every interface design program I've dealt with for desktop, nothing comes even remotely close to the ease and speed of simple WinForms in Visual Studio. Drag, position, rename, tweak a handful of properties, done.
|
|
|
|
|
In my opinion developing with XAML is a lot easier than it is with WinForms. I am not much of a designer but I like being able to write exactly how I want my UI to look without having to deal with the twitchiness of dragging and dropping controls. I don't even think I have the toolbox enabled for WPF projects. Never needed it.
|
|
|
|
|
 The Dog ate my Specs! 
|
|
|
|
|
|
Keeping complexity under control while new functionality is added to an existing system - especially under significant budget and timeframe pressure - there's a difficult one.
|
|
|
|
|
Not that different from whatever goes for normal development -- could be that todays phones/mobiles are quite well endowed compared to PocketPC / Windows Mobile and Palms from the previous decade.
|
|
|
|
|
Is finding out they changed their mind and don't need it, or their never using it.
That's worse, even, then having specs change to the point of unrecognizable viz-a-viz the original specs.
Paid for my time though-I-am, I still used up some life on this thing. After one cuts through all the shtakah*, one can at least get some positive payback seeing people using your stuff.
So, at least for me, the real and overriding hardest part is finding out the time was wasted.
* Understood by those who watch Defiance.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
... and that's why I got out of defense contracting. In the late 80's I worked for a defense contractor for three years. On one effort, where a team of us spent two years building an emulation of a flight control system, the project was delivered to the USAF, exercised for two weeks, and shelved. Another project was delivered, accepted, and shelved immediately. This was expected. This is demoralizing, to say the least. Out in the commercial world, at least people use my stuff.
I heard a statistic at the time. Based on $'s expended in developing a piece of software, the U.S. Department of Defense used only 2% of the software developed for it a year after the development was completed.
Software Zen: delete this;
|
|
|
|
|
Interpreting Specs (or lack thereof) & Dealing With Client
Pretty much synonymous in most contexts.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
In the last few years I've encountered infinitely more obstacles that stem directly from the place I work for than problems relating to technical issues or requirements.
- We almost exclusively use .net technology, so when someone wants to use MVC for a web application, we subject them to meetings about why and then make them write a business case for using MVC.
- Then do the exact same thing when someone wants to use a single third-party .dll from codeplex, stating that "An application should reference no more than three libraries" like it's enshrined in software development fact
- Then have more meetings about "why our ASP.net web application needs IIS"
- We don't/won't use UML in our 150+ project "framework", but we'll call meetings and invoke mini-sprints for "software architecture clarification" based on the whim of one long-serving part-timer, because he "doesn't like seeing a reference to System.ServiceModel in a client application", despite all the WCF client stuff being right in there.
- In our sprawling framework we just created we don't actually do much new stuff, bar inner-platform a manufacturer's API behind a facade. We've even kept the inherent problems with the manufacturer's data access layer: index-based access to columns, every value is System.Object, can't databind, transactions can't be rolled back
- Using Linq style paging using Skip and Take in EF or NHibernate is wrong as the database has to do all the work while the application waits. Instead, another long-serving "senior" recommends we "select everything from the database, then use Skip and Take on the data in memory. In-memory is faster.", even if paging in memory takes place on the other side of a WCF service boundary and the database has millions of rows
- Spend months speccing and prototyping a big data project by developing your own algorithms and ORM-incompatible stored procedures to partition a SQL table, when SQL already supports this OOTB and you can set it up in seconds.
- Complain to the MD about not getting a raise when he's just said there won't be any raises due to inefficiencies
|
|
|
|
|
That's probably about optimal. Nothing wrong there.
Regards,
Rob Philpott.
|
|
|
|
|
Instead of that I avoid coding on a new project for at least 2 days, but discussing it with collueges and drawing some UML stuff. I hold on to the paper stuff to learn from mistakes.
This prevents me from making some early bad decisions.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I wish I could upvote this more than once. The lack of attention that is given to standard, formalised technical designs gives our industry a bad name. Cowboy coding.
Another thing about this is that you can still get a position or a contract somewhere where UML and architecture were job spec prerequisites, yet when you perform this as part of your role it gets ignored. I've had several occasions where superiors have either not read the design document at all, or not understood it, yet have signed off the technical design. Come delivery time, they're the ones who complain that it's "not what we expected/wanted". It breeds a bad mentality in the organisation to say the least.
Would you willingly buy a car, take a flight or rail journey if you had prior knowledge that they just threw your vehicle together without designing it first?
|
|
|
|
|
I learned it the hard way: after some "Cowboy Coding" I saw that making some architectural design is more than worth its time.
It is well spend time - more than coding a lot of stuff which will get thrown into the recycle bin.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I had once a project on customer's factory...
First time I was there and saw that "standard", I had 2 weeks to make a modification and fixing some bugs.
1st day was a full day speaking with the mechanics of my direct customer and getting a good view of what has to be done.
2nd day was asking the maintenance guys of final customer about how the needed 3rd party tools worked and getting needed procedures to upgrade the stations.
3rd day I packed my laptop out, got the actual software, switched online and sit in front of the machine watching how it worked in production and how the program was reacting live.
3rd day in the afternoon my boss called me and asked me what I was doing, because the project manager of my direct customer had complained like "WTF is he doing here? 3 days gone and he (me) still did NOTHING and blah, blah, blah..."
4th day I start programming separated modules with debug items to see how some modifications would react in the production without changing the running code.
7th day I said the mechanics "OK, lets do the hardware changes". In the meanwhile, the project manager was already freaking out and got his complains to the president of the company I work, my boss was being pushed to remove me out of that project.
Day 12: I was done with the ToDo List I had and the final customer was so happy about the results, that he wanted me to modify other 2 stations.
Day 14: I went home having done all what I had to do plus some extra points being payed on a separated bill, because they weren't in the original contract.
Day 15: The project manager was forced by his own boss to write an email apologizing about the previous complains and saying thanks about the good job I had done
3 or 4 Months later, the final customer had some other modifications and they explicitelly spoke with the executive chiefs of my firm and told they wanted me to do them. 1 Year later another time.
Moral: It might seem a time waste to hold on and think on how to do it at the beginning. But good planned things, get through much smoother and faster than starting without having a clue and see what happens. Sometimes it is hard to make other people see it, but results speak for themselves.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Do some creative work is hard. Sometimes it is worth it - sometimes not. I have experienced that it is essential to know, whether some creativity is awarded, or someone wants (or deserves) "Quick and Dirty" job.
I have this week struggled to some OpenGL 2.0 stuff and now that I understand I will delete 2/3 of the code I have written in my sample app. So anybody will I see what I had written but know I understand OpenGL a bit 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
