|
It is the most muddy topic. I thing the natural human language is not suitable to create the short and self-constistent requirements.
|
|
|
|
|
We build commercial ink-jet printing systems, so for us it's testing.
When we do have a machine to test on, there is a set schedule for each group to get test time on it. 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. We've had engineering prototypes for new products sold out from underneath us.
"It's a madhouse I tell you! A madhouse!"
Software Zen: delete this;
|
|
|
|
|
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. It happened to me as well in past. Only option was Trial and error[^] which was really a terrible time consuming process & BORING one
|
|
|
|
|
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?
|
|
|
|