|
Allow me to explain, THE PERCEPTION PROBLEM, which has to do with the SIZE OF A PROJECT.
Back around 2000 - 2001 I worked with 3 other programmers who were Visual Basic 4.x,5.x,6.x devs.
VB didn't support true OOP principles.
Well, along came ASP.NET and we had a project which required a navbar which would allow the user to nav back and forth through the numerous forms so a user could enter his/her data in a structured way. This nav bar would also have the ability to put the form into edit mode -- when the user first viewed it the page was in read-only mode.
Roots of the Perception Problem
At first the project was small and the user was only going to have to navigate about 4 pages.
So those VB Devs said, okay, we just generate some HTML which we copy/paste to the top of every page.
No big deal.
I said, "Terrible idea. it'll break and drive you crazy. ASP.Net lets you turn that navbar into a control so you can write the code one time.
"Uh, our way is easier," they said. "I mean, hey, we copy and then we paste."
I went ahead and implemented mhy navbar as a UserCtrl and placed it on the few pages I had to develop. It worked well and when there was a problem I went to the NavBar class files and fixed the code.
Scope Creep: The Monster
Meanwhile, the project grew -- major scope creep -- because the users wanted more forms.
Now those guys were copy/pasting to something like 30 pages.
The navigation had to know which page was next, so they had these hard-coded values which indicated the next page and if there was a next page and all that. So they are typing these values in to these pages.
The Deployment Explosion
They finally deployed the beta to the internal users and it blew up every time they clicked the navbar to set edit mode or go to the next page. It got lost in the form flow. Total failure and the internal users think our group is filled with idiots -- kind of was.
The Big Fix - One OOP Control
The Project Manager came back completely dejected. I said, "Hey, I can put my control on there and those pages will work in a couple of hours."
"Sure, right. Go ahead and try it," they said.
Ripped their confusing copy/paste navbar out, replaced it with the UserCtrl and tweaked a few things and it worked great.
Summary of Problem
They probably could've gotten away with copy/past development if it had only been three pages, but as soon as there were more pages it became expoenentially more difficult to fix their problems because they had to go to every aspx and edit the nav code on their page. Crazy. Insanity.
Mine took a bit more work up front, but then you could go to one place (UserCtrl) and enhance or fix it any time.
That is the power of true OOP. TRUE OOP with TRUE OOD.
The Difference Is In The Disciplines
It is interesting because those VB Devs learned to code by typing. Type, see if it works.
I believe in that method for learning, but for designing, it is a terrible way to create code. These guys were really just advanced scripters -- even though a couple of them had MS certs. Ugh!
I on the other hand, started out learning C++ and OOP. I always questioned what the point of OOP really is. Why OOP?
Why? Why would we do things that way? I can write 2 lines of code that do that thing. Why OOP? Why?
Large Projects
Because for larger projects things need to be organized and OOD/OOP are really a way of organizing things so that when they get so complex that you can still manage them.
|
|
|
|
|
newton.saber wrote: So those VB Devs said
Therein lies the problem. 
Once you lose your pride the rest is easy.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Yep, you know them (vb devs)... 
|
|
|
|
|
Great example; thanks for sharing! 
|
|
|
|
|
I like kissing, but I digress.
 (with the tongue!!! OH_WAIT not KSS)
I'd rather be phishing!
|
|
|
|
|
"KISS" is in the eye of the beholder.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
KISS is not a bad concept in itself, at all.
Problem is that morons often erect it to a dogma to hide their own limits.
Don't bother about them; anyway you have your boss' approval.
Courage!
There are two kinds of people in the world: those who separate humankind in two distinct categories, and those who don't.
"I have two hobbies: breasts." DSK
|
|
|
|
|
Having been on both sides of this coin, I can sympathise with both parties.
I've introduced things like knockout and been met with resentment, but I've also been in the situation where devs have introduced stuff for no better reason than 'its new and interesting' or 'I've always done it like that'.
My advice, FWIW, is to follow these steps:
0. Be prepared to admit that you are wrong and they are right. Of course, it's not the case, but be prepared.
1. Put aside some time for you to train them in the things you want to use - with the caveat that this may be wasted time if you all decide not to use it.
2. Out aside some time for them to train you in their alternate techniques - with the same caveat.
3. All sit together and prepare a list of pros and cons for each.
4. Decide which has the better score in the pros vs cons lists
5. All agree on the outcome, be happy, and get on with it.
It helps if you have a relatively non-technical person involved in the process, as they can ask the dumb questions and make an independent assessment.
|
|
|
|
|
Ho, I can see you are experienced with that kind of situation!
Well, I will certainly keep that in mind for next time!
At this time it is too late, there was no sensible discussion possible with the other party!
The most agreeing exchange I had was: ME: "let's refactor it together the way you like", them: "I have no time for that"...
|
|
|
|
|
What I find more troubling is that you have a maintenance team and a new development team. Also, you aren't coordinating. Knockout is a big change. What kind of training have you done to make sure the entire team is up to speed with it?
When I made the choice to use angular, I went over all current major frameworks at the time and we debated the pros and cons before we all thought angular was a good choice. Then we built some prototypes with it just to make sure.
|
|
|
|
|
Maybe I was cavalier indeed. I didn't like web development at all, kind of sad doing it. Then I discovered knockout and that I could make quite advanced web app with little effort. Then the customer wanted a new application and we had time to build a prototype. The customer loved my prototype a lot and were quite impressed with it!
But some developer hate the technology choice I made. Or the one I didn't make. As far as I can see I can only humanely do these kind of application with knockout or angular (or my own big library). But they hate either choices. And the customer really like my prototype!
So my choices was:
1. continue doing spaghetti giant jQeury even handling and DOM manipulation with primitive table CRUD operation
2. sell a (more pleasant to me and more user pleasing) new concept, which displease some other developer
I choose 2, maybe I should accept the consequences... but I am ... frustrated...
Isn't it part of developer job to keep with the time? Isn't that so much easier when handled a working code base on a platter (as opposed to have to implement it on your own)?!
|
|
|
|
|
The problem isn't with the technology. Knockout is much better than hand rolled jQuery all over the place. It's with the communication and management of the team.
|
|
|
|
|
So offer to do a training session, where you can show people how to use ko statements, and show them how much easier their lives will be with them.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The PM suggested that... I dunno what kind of communication took place between the PM and them. Dunno what they make of this idea... 
I don't think that's going to be any relevant for them for a few more months.. (until we give them the application, which is not quite ready now, by a long shot...)
|
|
|
|
|
I love the KISS (Keep it Stupid Simple) approach. I find that for each hour of new development, in the two years after that, it will generate at least another 8 hours of maintenance: changes, additions, optimization, troubleshooting and bug fixes.
Of course I don't know your case specific scenario, and replacing 20 lines with one line that can be much better and easier to maintain than the 20 lines.
But if you can fall on many aspects:
- Is it easy to understand for someone else than the author? (or even for yourself 3 months later?)
- does it require - yet another technology - that may disappear or get replaced by something better in 6 months? You don't want to get to a project that before someone can start to work on it they have to understand seven different components, techniques, conventions or technologies.
But then again, kiss is subjective.
|
|
|
|
|
The thing is "simple" is relative. Depending on your skill level anything can be simple. Try and explain why it is more efficient and make sure that it is clear through the code what it actually does. The code has to be maintainable and work. That's it.
|
|
|
|
|
I would suggest that you inform your maintenance team about the subtle but crucial difference between "simple" and "simplistic" 
|
|
|
|
|
There are no 20 lines of code that are simpler than 1 line of code (assume that it fits in 80 characters margin), unless 15 of those lines are comment. The idea of dynamic languages is the model, not the structure. If you want a structure, you can stick with java - there zero lines of actual code require at least 20 lines. In dynamic languages the complexity of the task/model (which should be understood if you try to understand the code) is directly related to how much lines you use - less lines = much simpler (but that does not apply to unformatted code).
|
|
|
|
|
When I started my first programming job the team were using legacy C libraries from another company that were old, clunky, terrible to use, full of bugs and required a lot of typing. When creating new programs they copied forward an existing one that did most of what they wanted to do and added a load more code, commenting out any bits they didn't need just in case when it copied forward again the original code would be in there. It was a bit of a mess!
I learned their libraries inside out, but instead of saying, all your code is awful why don't you do X, I set about rewriting them a tiny bit at a time and slipping the code into the programs; at first people didn't really get it but after a while (and it was a while) they realised ways of doing things had the same/better resulst and took less typing and started doing it in the different way.
Some people don't like change and will cling on to old methodologies and code because it's either what they know and can do, they don't want to put the effort in to learn anything new, that or they think you are usurping them in some way and if they "allow" you to "update" things it implies they were crap in the first place for not doing that ages ago. I'd recommend starting very small or moving to a department/company that likes moving things forward at a faster rate.
tldr;
I'll let future me worry about this.
|
|
|
|
|
It sounds like what your company really needs are regular technical sessions whereby any developer can do a quick demo of a particular technology or framework that they think is useful.
Getting all the developers together with a 10-15 demo showing what Knockout can do, how it reduces the amount of code you have to write, how easy it is to make things work, and how it would make future maintenance much easier would get any professional developer on board.
If it doesn't, I'd start looking for another job.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
This sounds like a good idea!
Although this won't really work in our case. I work at a consulting company (the best one I have been at so far! ) so we are all dispatched to different client and do not really work together!
Although some developer did mention they would like some technical meeting like that to happen... I wonder...
|
|
|
|
|
One line of framework code is not necessarily simpler than 20 lines of lower level code if people don't understand the framework, if the framework is complex or a maintenance headache in itself, or if the framework doesn't naturally fit the problem and you end up with 30 extra lines elsewhere to work around it or set it up. Simplicity is not just a measure of code size, it's a measure of understandability, and if a seemingly simple framework call is doing a lot of stuff that people don't understand, it isn't simple.
(To use a different example, .Net Task spawning code looks really simple. new Task(lambda).Start(), what could be hard about that? But to understand that one line, you need to understand threading, thread pools, synchronisation/locking concerns, marshalling UI calls to the UI thread and so on, and if you don't, it is harder to maintain Tasks code than it would be to maintain the longer but more explicit manual thread management code.)
Those things may not be true in your situation with Knockout.js, although the first one clearly is, but it is the responsibility of the person who wants to bring a new framework to a project to introduce it to the team and make sure that it really does make the team's life better, not just yours.
You mention lambdas and generics in your edit. I've been 'that guy', particularly with generics – but I won the argument because I could explain why the generic code was simpler and that it was worth the investment to learn.
|
|
|
|
|
You make a good argument ...
But it doesn't quite apply in my case.
I don't even work with this maintenance team. Have no regular work-tech meeting with them. They just had a look once at the repository.
When I meet them informally, say for lunch, I hear a lot of complaints... I even say let's "sit together" but guess what? "there is no time"!
As for the people I work for? They are all converted by now!
|
|
|
|
|
Well in that case if your PM is onside, just tell them they're wrong, that they need to go learn about the technologies used in the application they're maintaining, and direct them to the PM if they start an argument about it.
|
|
|
|
|
Part of working successfully as part of a team is consideration for others. If you're not able to calmly and logically persuade them to your point of you then I am afraid you will have to swim with the tide. Regardless of who is 'right' or 'wrong' or how much it costs for either party.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
