|
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.
|
|
|
|
|
Yeah I hear that. Part of me finds some amusement in this. Humility is the seat of wisdom. Pride makes people do all kinds of foolish things.
Real programmers use butterflies
|
|
|
|
|
I worked on a project where the developer followed a lot of patterns to the point where there just too many layers. It makes maintenance difficult. There's a balance between having a system easily extendable (not a monolith) and having too many layers.
|
|
|
|
|
I totally agree. This is pretty much what i was ranting about.
Real programmers use butterflies
|
|
|
|
|
After 5 years of academic research on the subject and 6 years of commercial R&D as primarly a software architect, my conclusions are very similar to yours.
A low learning curve and straightforward structure that only slowly gains complexity over time, is the best possible outcome.
Now, for the last 2 years of working in an almost-enterprise level company, I also notice that almost no-one correctly values that conclusion.
Some scoff at the simplicity, and take it as a personal challenge of sorts, because they've been openly passionate about more intricate solutions in the past. Some drastically undervalue the effort involved, as they equate "simple" with "not a lot of work" and immediately try to displace it with, somewhat ironically, an off-the-cuff idea that's incomplete and more complex to execute.
Let me give you some advice on how to deal with these people.
Instead of explaining why a low learning curve is an integral part of a good design, let them present a small practical example of their own proposal, and give them an audience that judges them on how easy it is to understand, and how easy it will be to maintain.
In my experience, most people take on the bait in a heartbeat. About half quit once they realize their mistake (they tend to recognize the 1+ pages of "having to explain basic stuff first" as a failure and a lesson in humility) and the ones that do present their solution, often feel embarrassed about the whole thing once they realize no-one really understands the words they are saying.
Lessons will be learned and egos will be bruised. Keep a respectful tone throughout and you'll manage just fine.
|
|
|
|
|
That's some great advice. I'm freelance now doing IoT stuff so there's no room for GoF patterns and UML in my code - simple is king, and I love it but I'll definitely give what you said a try should I find myself in that role again.
Real programmers use butterflies
|
|
|
|
|
"Quote: let them present a small practical example of their own proposal, and give them an audience that judges them
The usual problem is the way those more senior do it to the architect, having set out a basic structure and asking for the gaps to be filled.
But you are right, it's best if you can manage to explain the complexities and difficulties first, before showing the excellence and simplicity of the system design!
|
|
|
|
|
I guess I was an old school architect.
We typically wrote prototype code for how we wanted to interface with the system, then we went back and designed a system architecture that we could use for those things.
We didn't do UML diagrams, or go crazy with patterns, although we had a few singletons. We did use streams between client and server, and that made adding compression a breeze, and later encrypted the compression a breeze. A few lines of code allowed the server to know if the client supported compression and/or encryption. And then it simply constructed the "best" stream object. The clients abilities were known, so it handled what was streamed back. The server was ALWAYS ahead of the client, so it did not have to worry, the old clients NEVER asked for encryption or compression.
But I completely agree to a point. I see these complex designs and I wonder.
Although I am pretty impressed with most of the RESTful style APIs.
QuickBooks Online being the EXCEPTION. Imagine having a Memo Field on an invoice.
Imagine Importing an Invoice, that Identifies the Memo field. Imagine NOW that they put that on the CUSTOMER STATEMENT and NOT on the Invoice. No option given to have it be on both or be on the Invoice.
Worse, if you have a default Memo defined. And you do an import WITHOUT SETTING the Memo, it does NOT use the default value the way it would if a User Created the invoice. But you can use ANOTHER API call, and set the Invoice Memo Field after it is created.
That kind of stuff drives me BONKERS. It's like the programmers have NEVER USED their own system!
Google Tasks. Last I checked does not easily let you move a task from ONE task list to another. How swell... You have to copy all the fields, and create a new one, and then delete the other one. God forbid if they add a new field you forget to copy, or the field can only be set AFTER the task is created. LOL...
I yearn for simpler days in some ways, and at the same time I pray things keep improving...
|
|
|
|
|
Left to my own devices, that's pretty much how I design.
The exception is when I'm working with a large team on a huge project. Then the documentation features of UML and the heavy abstractions can *sometimes* be handy.
Real programmers use butterflies
|
|
|
|
|
I totally agree. Have you seen my signature?
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
|
|
And it only costs that much because of student loans. But at least the typical MIT degree teaches something useful.
|
|
|
|
|
Anyone from a family that makes less than $100,000 a year is very likely to have their education paid for them. Having a multi-Billion dollar endowment allows MIT to subsidize most, if not all of their tuition and fees.
|
|
|
|
|
I didn't realize this was typical at MIT, which must be in a minority of schools given all the student debt out there.
|
|
|
|
|
obermd wrote: Anyone from a family that makes less than $100,000 a year is very likely to have their education paid for them
Please tell me that's an MIT thing, 'cuz I sure never received that check.
|
|
|
|
|
Interesting, if a little long, article. 
Sadly, the truth is, a degree, (particularly from a top University), is way too highly valued by most employers. I don't have a degree and, after being made redundant 8 years ago, I was dumbfounded to find that I was getting job application rejections because of this. To put this into context: I have been in IT for 40 years; ran a Software House for nearly 10 years; and was head of IT for a multi-national with a $Billion turn-over for 18 years.
The fact is, it's just lazy recruitment.
|
|
|
|
|
5teveH wrote: I have been in IT for 40 years; ran a Software House for nearly 10 years; and was head of IT for a multi-national with a $Billion turn-over for 18 years.
"So what ? My automatic search algorithm did not find the degree in #+#+# that is required for the job from the SW department, as opposed to this fresh-from-the-university-still-drunk-from-spring-break underpaid junior, who will probably be hired for the job", says HR in probably most companies.
|
|
|
|
|
I tend to think that it works both ways, if a company is not wiling to hire a person based on their experience and work ethic then it's probably not a company worth joining.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
|
As an MIT alumnus, a starting salary of $250K is definitely not worth it. However, MIT teaches it's students how to think through complex problems and solve them. These are skills that are worth a lot in today's society.
|
|
|
|
|
That's what Master's programs are for. And most people do those while working full-time.
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
