|
 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
|
|
|
|
|
There's so much productivity tools on the market today and new tools, frameworks and even languages are appearing almost daily.
But how the hell will we use them if we can't even get our specs straight?
It seems we're solving the wrong problems... 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Making deadlines and ending up with a profit.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
Software App/Product/Project is very funny things, What you mean by Deadlines (Do we follow them  )
Really, Software app development is bit "Rocket Science" 
see below points about software app
- Walking on water and developing software from a specification are easy if both are frozen
- Programs must be written for people to read, and only incidentally for machines to execute.
- Any simple problem can be made insoluble if enough meetings are held to discuss it.
- The software is not finished until the last user is dead.
- Why do we expect documentation to accurately describe the product when the documentation is finished first?"
- When you spend time to find & fix all the bugs in your project, you can't complete the project in your life time.
- We did execute about 10,000 test cases on it, and it was working fine until Monday.
- Software has following options but you allow to pick any two : Fast, good, cheap
- Your problem is another's solution; your solution will be his problem
- There is no "improve performance" checkbox in any software
What else to say
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
|
Well not all, but some of them are just bloody idiots!! 
Whether I think I can, or think I can't, I am always bloody right!
|
|
|
|
|
Can't help it. Consider those "Gods gift to IT" as "Professional Hazards" 
|
|
|
|
|
And estimating time lines.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
You are absolutely right, but let me suggest you a formula to calculate time for development.
I ask my team how much it will take, everything they answer I multiply by 5 and pass over to CEO. He doubles it and add some for QA. From that those in charge of customer care create a proposition (with added day) and pass it (with cost attached) to the customer.
In most cases the development over before we get an answer from the customer (we have over 10 little gems that got developed in this way and the customer banned it)...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
What I actually experience is when I give my time estimate for a certain project. They will cut it and ask me to accomplish it sooner. So what's the use of my time estimate?
Don't mind those people who say you're not HOT. At least you know you're COOL.
I'm not afraid of falling, I'm afraid of the sudden stop at the end of the fall! - Richard Andrew x64
|
|
|
|
|
100% agree... Its always a case of (time it would take/2)
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
That is why you always at least double it from the start and never tell them you did...
So many details! (heavy sigh) So much confusion...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
