|
I worked in a couple of places but maybe because I would not fit in "just code that, no questions asked" approach I am biased.
|
|
|
|
|
Quote: I'm also going to come out and say it makes things harder to maintain. When you're working with 20 different classes and interfaces where 3 would do it just increases the learning curve. There are definitely diminishing returns when it comes to decoupling software from itself, and you run into the cost/benefit wall pretty fast. It can only take you so far. It's best not to overdo it.
I would be very careful with the "3 would do it" part. SRP should always be respected otherwise you will get burned really bad sooner or later. I agree that overdesign is a waste of resources, yet underdesign tends to cause much more damage. If you design something with hundreds of entities and expect it to remain maintainable for 5+ years, initial investment into architecture pays off. Of course, if the architect is well familiar with both application architecture practices and the domain of the application.
|
|
|
|
|
Niemand25 wrote: agree that overdesign is a waste of resources, yet underdesign tends to cause much more damage.
I'm not advocating for doing away with the design phase. I also think that while what you say is true, people are also taught this heavily, and I think they take too much to heart. Maybe that's what it is too? Maybe people get so afraid of a deathmarched project that they overengineer everything?
Real programmers use butterflies
|
|
|
|
|
As you agreed in other post. Overdesign is rare if compare to underdesign. Which makes its impact quite low. At the moment I'm angry with myself as I one more time cut corners due to time pressure, disrespected SRP and now fixing my mess 
I guess the time pressure is the reason for underdevelopment and (for the most part) effectively prevents overdevelopment. Not that many developers have spare time to go to the jungle of abstractions and irrelevant use cases.
|
|
|
|
|
Niemand25 wrote: Not that many developers have spare time to go to the jungle of abstractions and irrelevant use cases.
That's probably why I see so many offending projects posted at CP.  Rarer in the field sure, but when you have a pointy haired boss who just heard about UML at a conference and now wants to impose it on every project it can make it near impossible to make deadlines.
Real programmers use butterflies
|
|
|
|
|
Bosses are ... well ... bosses 
Not the worst case, I met a head of DBA's in one international company who never heard of normal forms. Discussion between her and reporting team was marvellous. She couldn't understand why reporting team are so much displeased about xml in fields. It is so easy to parse, isn't it? 
|
|
|
|
|
Hahaha whoops. Although in fairness, I *became* a DBA out of necessity because a lot of smaller shops I worked for in the late 90s and early aughts had nobody and no clue. I can respect having to learn on the job, but the key is to *learn* on the job.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: ust because you know how to do something doesn't mean you should.
I look at that the other way:
I don't know how to do something so I do it. That philosophy is, after all, what makes our world go round.*
Bitterness section - or perhaps just bitter-sweet:
Let the next generation sort it out instead of staring at their cell phones.
*like it or not - and thus giving you the answer to the great philospher's question "Why?"
| 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 seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
honey the codewitch wrote: Keep It Simple Stupid.
The golden rule. 
|
|
|
|
|
"Simplify, simplify" -- Thoreau
I totally agree, but I prefer to work alone anyway. I never begin with much of a plan, I simply begin and see where it goes.
Twice I recall being handed a "spec" for something I was to develop, but I ignored them and did what I knew was right -- one of the specs was actually dangerous.
Specs always come from people who have no idea what they're doing, but want to appear smarter than the people who do.
For one personal project, I made kind of a grid to track which features needed to be developed, which didn't, and which I had completed, but that's about it.
|
|
|
|
|
|
(hence) Never use technical words for pictures.
Never tell customers, or developers, that the picture is UML - it's just a picture 
Guidance of the wise...
|
|
|
|
|
It takes a certain talent to be able to code like that, and I respect it. Naturally I do, because I'm much the same way when left to my own devices.
It's useful to know architecture, UML and all of that mess just to be able to communicate with people who speak it, and I will concede that huge projects with large teams pretty much demand architecture and pre-planning but otherwise just let me at the code.
Real programmers use butterflies
|
|
|
|
|
This is just as true for "frameworks". When was the last time a generic framework actually did what you wanted it to do?
|
|
|
|
|
Yes. Although I'll grudgingly accept that for its size, Microsoft did a fair job with the .NET BCL
Real programmers use butterflies
|
|
|
|
|
Well, a framework isn't supposed to do anything!
|
|
|
|
|
Like everything in life and art, there are two faces to this coin: at one extreme you have spaghetti code and at the other you have massive libraries of hundreds of classes and structures (I'm looking at you LEDA and BOOST). The golden path is in the middle. Our job is to find that middle path.
I heard someone saying that engineering is the art of finding when one is approximately equal to two and when one is much smaller than two.
I let you with these two quotes:
“Everything should be made as simple as possible, but no simpler.” - A. Einstein
"You should be glad that bridge fell down - I was planning to build thirteen more to the same design" - Remark attributed to I. K. Brunel, addressing the Directors of the Great Western Railway.
Mircea
|
|
|
|
|
Mircea Neacsu wrote: “Everything should be made as simple as possible, but no simpler.” - A. Einstein
I *almost* dropped that quote in my rant, and I bring it up all the time when it comes to software. 
Mircea Neacsu wrote: "You should be glad that bridge fell down - I was planning to build thirteen more to the same design" - Remark attributed to I. K. Brunel, addressing the Directors of the Great Western Railway.
Haha it's funny because it's true!
Real programmers use butterflies
|
|
|
|
|
My first recollection of "software life" was 5 years.
The "architecture" issue I see is most are into "piece" work; without caring / knowing / wondering how it fits into a bigger picture. The million (code) monkeys and a million keyboards and eventually we get some useful algorithms / patterns.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
OK, I had to look up UML...heard of it long ago and found it useless. I'd rather keep these diagrams in my head...much easier to update/maintain!
IMHO, a good database design tells the whole story. Most abstraction can be handled in views/procs. (talking lob apps here)
BTW, in 20+ years I've never seen a specifications document/plan. The closest thing might be an occasional UI mockup in a screen grab or worse, scribbled on a notepad. (or even worse, a screen grab of an image of scribbling on a notepad!  )
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Yeah it's a little different when you're not doing business apps. IoT devices, developer tools, that sort of thing, you don't have a database to go by necessarily. Although I'd also argue that any validation those procedures are doing in them should be done on the front end as well to avoid bad/spurious network traffic. If they are well designed, hopefully they add to the story. 
Real programmers use butterflies
|
|
|
|
|
kmoorevs wrote: TW, in 20+ years I've never seen a specifications document/plan. The closest thing might be an occasional UI mockup in a screen grab or worse, scribbled on a notepad. (or even worse, a screen grab of an image of scribbling on a notepad! )
The last major gig I had had a very good specification plan from which I was to code. As I got into the meat of the task, there were a few items that seemed to be very difficult to implement - i.e., would need to build a new UI control and access 3rd party stuff (YIKES) - that I was able to talk the program manager out of due to the difficulty. The app was meant to be used by the USA military out in the field, so I was able to explain how simplicity would be an asset.
|
|
|
|
|
Quote: decoupling software from itself
I like that phrase!
Though I wish, when it comes to people, some people were more decoupled from themselves, and others less decoupled.
|
|
|
|
|
Upvoted, just because of the endless interpretation possibilities.
|
|
|
|
|
My take on this is that people feel that if they won't "foresee and prevent" some issues like duplication of code they are lesser coders.
I try to explain that we should use rule of 3, so if it is in 2 places that is still not duplication of code. But what I get in code reviews and discussions: "you violate DRY" like it would be some holy grail and you are lesser human if you have 2 lines that look alike.
Reality is, that this emotional problem not technical. Usually people want to do a good job or be better than others in their work. I can point out 10 logical reasons for why those 2 lines should not be changed into single line, but it is still not going to convince someones pride.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
