|
... comments which are too personal for my own review.
|
|
|
|
|
... to blow it into pieces after the first cycle...
I saw it a lot of times... The first cycle (kind of prototyping) is - in most cases - very simple, but full of show-offs (that's how we buy time  )... At this point the good old PM feels he can cross the rainbow... we all doomed...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
I can stop one, but we have a bunch of them 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
It was a close tie between "Deciding on a language / framework / stack to use" and "Working out the basic architecture" as these form the basic building blocks of the application (I chose the latter in the end but it was difficult to separate them). If you get one of these wrong, your application is going to (probably) suck.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
No name, no app!
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
One of the first things I ask after I get the initial request - What do you want to call this solution. At which point they either shrug and leave up to me or real off a 200 character description of the app.
My latest one was name CQAD - CAR Quick And Dirty - finance were not impressed when I deployed the first UAT version. My response was you leave it up to me you take what you get.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I like to use whimsical sounding names for apps.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
One day I'm going to run out of Greek and Roman Gods to name things after. I'm going to start on Norse gods after that.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Yet Another Missing Option: maintenance of the app, especially when you're the latest in a long, long line of developers who've messed with the code. As an example, I just finished fixing a long-term set of bugs in a piece of software for one of our products. Parts of the code are 25 years old, the original developer has retired and the principle engineer on the current revision passed away a few years ago. The corrections totaled less than 50 lines of code. It took over 200 manhours of work by myself learning the code base from scratch, two additional engineers, plus a very cooperative customer to diagnose the problems.
I now know all too much about how to implement a TCP/IP stack in an embedded environment, and Wireshark[^] is my bitch.
Software Zen: delete this;
|
|
|
|
|
Or did someone "hack" the list and remove it?
For anything web deployed or deployed as a "live" service, this is a critical step.
|
|
|
|
|
But surely it's not a separate activity; it's part of the whole "choose a platform", "design an architecture" and actually building the thing.
|
|
|
|
|
... because when I write my own stuff, I'm not bogged down by someone's delusions. That leaves me too much time for some ideas of my own.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Then, again, it's easy to find a dirt road for sake of the back window.
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
Deciding which of the above is the hardest!
... such stuff as dreams are made on
|
|
|
|
|
Rapid application development: the process by which we can get 99% of the job done in next to no time, saving us a great many hours which we can spend on the other 1% of the job.
98.4% of statistics are made up on the spot.
|
|
|
|
|
"98.4% of statistics are made up on the spot." ... did you made that one on the spot?! Lol! 
|
|
|
|
|
Procrastination is often confused with the mental work of thinking through edge cases, designing data structures, UI layout/elements, etc. and it works differently for everyone. I'm not being lazy, I'm doing work in my head!
"Go forth into the source" - Neal Morse
|
|
|
|
|
Great, got me many laughts ... "I'm not lazy, i'm working in my head"!
|
|
|
|
|
I'm not lazy, i'm working in my head about what to reply in the comments 
|
|
|
|
|
Unfortunately, the requester rarely knows what they really want it to do. So much time explaining to them how an idea they have needs to be modified (for flexibility, for example, or more so, usability).
Some get it - they're great to work with. They have an idea and a need and I make it happen, often a little more.
Some just think they know better. There must be a place for those applications similar to the post-office's "Dead Letter Office".
I try to explain to them: Don't ask for everything you want - keep it limited to everything you need.
That, I'm afraid, is why sometimes even I call what we do "Work".
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "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 |
|
|
|
|
|
One of the textbooks I read for the Systems Engineering course presented a list of "Factors that may delay your project". It included "The customer is inexperienced in data processing", and a little further down the list "The customer is experienced in data processing".
This is long ago, when there were people who had no experience with computers and data processing. Today we might add a third option "Customer believes he is experienced, but in fact doesn't understand a sh*t".
On the more serious side : Seeing the customer gradually brighten up and becoming increasingly more eager as he begins to understand what he is really doing, is one of the my great pleasures at work. Actually, one of projects I was involved with didn't include a single line of coding: The task was to create a complete data model (in those days it was an Entity-Relationship model - an excellent modelling tool!) for the total information flow in the city administration of a town of 200.000 inhabitants. Years later they thanked us for helping them clean up their manual procedures!
On a smaller scale, I have had similar experiences several times: Helping the customer understand what he is really doing, is a great pleasure, and is essential to building a system that satisfies the real needs. Plus the customer.
|
|
|
|
|
Member 7989122 wrote: Customer believes he is experienced, but in fact doesn't understand a sh*t
A bit worse, now? They think that that using their phone makes them tech-savvy. After all, doesn't the TV, which they stream on their phone, tell them that?
The occasional bit of sparkle is that user who can understand how I need to (actually like to) turn their work into an abstraction. What is it they are doing, in general. What processes are really just the same process with different makeup and shoes. And this few, once they get the idea, also realize that their shiny new application is both robust and extensible, which are two words they can throw out at a meeting, showing how savvy they are.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "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 |
|
|
|
|
|
Shooting the engineer and going into production.
|
|
|
|
|
|
If it's worth doing then it's worth overdoing.
No, go and lie down until that thought passes.
Stick to the spec and if it goes wrong blame the authors.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
