Programming in different directions...
-
My company is currently working on a new project. I am basically the lead programmer. However, I have my boss (also a programmer) supervising me. I have recently looked into some design principles and design patterns. My boss has not (but is working on it)... So now we have the following situation, I want to make flexible and reusable software, while my boss wants to be able to make new classes and implementations quick and easy (but using a layered application and Entity Framework 4)... This has resulted in me making a generic class that goes with multiple generic interfaces that could handle any class that implements at least one of those interfaces (but every class needs its own implementation)... And my boss undoing most of my work (no more interfaces) and making use of Entity SQL giving every class the same basic functionality (no matter if it uses this). My boss' approach requires passing strings etc. my approach was always strong-typed. Actually now that I think of it, my approach could possibly support my boss' approach while this does not go vice versa. I am not saying his approach is plain wrong, but let's just say it does not have my preference. Are we programming in different directions or what? :confused:
It's an OO world.
-
My company is currently working on a new project. I am basically the lead programmer. However, I have my boss (also a programmer) supervising me. I have recently looked into some design principles and design patterns. My boss has not (but is working on it)... So now we have the following situation, I want to make flexible and reusable software, while my boss wants to be able to make new classes and implementations quick and easy (but using a layered application and Entity Framework 4)... This has resulted in me making a generic class that goes with multiple generic interfaces that could handle any class that implements at least one of those interfaces (but every class needs its own implementation)... And my boss undoing most of my work (no more interfaces) and making use of Entity SQL giving every class the same basic functionality (no matter if it uses this). My boss' approach requires passing strings etc. my approach was always strong-typed. Actually now that I think of it, my approach could possibly support my boss' approach while this does not go vice versa. I am not saying his approach is plain wrong, but let's just say it does not have my preference. Are we programming in different directions or what? :confused:
It's an OO world.
Sounds more like parrallel, at least your both working with some form of OO persistance. Always been a fan of strong types ;P
-
My company is currently working on a new project. I am basically the lead programmer. However, I have my boss (also a programmer) supervising me. I have recently looked into some design principles and design patterns. My boss has not (but is working on it)... So now we have the following situation, I want to make flexible and reusable software, while my boss wants to be able to make new classes and implementations quick and easy (but using a layered application and Entity Framework 4)... This has resulted in me making a generic class that goes with multiple generic interfaces that could handle any class that implements at least one of those interfaces (but every class needs its own implementation)... And my boss undoing most of my work (no more interfaces) and making use of Entity SQL giving every class the same basic functionality (no matter if it uses this). My boss' approach requires passing strings etc. my approach was always strong-typed. Actually now that I think of it, my approach could possibly support my boss' approach while this does not go vice versa. I am not saying his approach is plain wrong, but let's just say it does not have my preference. Are we programming in different directions or what? :confused:
It's an OO world.
I would suggest you sit down with your boss and start defining the architecture of the system before you do any more coding. Unless you are both working on the same page, your app will end up a disaster.
-
My company is currently working on a new project. I am basically the lead programmer. However, I have my boss (also a programmer) supervising me. I have recently looked into some design principles and design patterns. My boss has not (but is working on it)... So now we have the following situation, I want to make flexible and reusable software, while my boss wants to be able to make new classes and implementations quick and easy (but using a layered application and Entity Framework 4)... This has resulted in me making a generic class that goes with multiple generic interfaces that could handle any class that implements at least one of those interfaces (but every class needs its own implementation)... And my boss undoing most of my work (no more interfaces) and making use of Entity SQL giving every class the same basic functionality (no matter if it uses this). My boss' approach requires passing strings etc. my approach was always strong-typed. Actually now that I think of it, my approach could possibly support my boss' approach while this does not go vice versa. I am not saying his approach is plain wrong, but let's just say it does not have my preference. Are we programming in different directions or what? :confused:
It's an OO world.
Fix the team issues first. Second:
Naerling wrote:
I want to make flexible and reusable software
Many horrible systems have been born from that statement. I've created a few myself. Don't write a single line of code for changes that aren't needed right now. Stick with simple objects and only add interfaces if the class needs it to make the code simpler and easier to understand.
Curvature of the Mind now with 3D
-
I would suggest you sit down with your boss and start defining the architecture of the system before you do any more coding. Unless you are both working on the same page, your app will end up a disaster.
I agree... having an app that has completely different coding styles is not good at all, long term support will become a big issue.
-
I would suggest you sit down with your boss and start defining the architecture of the system before you do any more coding. Unless you are both working on the same page, your app will end up a disaster.
It really surprises me how many ppl start coding without agreeing on a standard or style... should definitely be a conversation that happens very early on
-
My company is currently working on a new project. I am basically the lead programmer. However, I have my boss (also a programmer) supervising me. I have recently looked into some design principles and design patterns. My boss has not (but is working on it)... So now we have the following situation, I want to make flexible and reusable software, while my boss wants to be able to make new classes and implementations quick and easy (but using a layered application and Entity Framework 4)... This has resulted in me making a generic class that goes with multiple generic interfaces that could handle any class that implements at least one of those interfaces (but every class needs its own implementation)... And my boss undoing most of my work (no more interfaces) and making use of Entity SQL giving every class the same basic functionality (no matter if it uses this). My boss' approach requires passing strings etc. my approach was always strong-typed. Actually now that I think of it, my approach could possibly support my boss' approach while this does not go vice versa. I am not saying his approach is plain wrong, but let's just say it does not have my preference. Are we programming in different directions or what? :confused:
It's an OO world.
Yes, the problem is that there should be only one who decides about the architecture. No matter who, but only one. Constantly undoing each others work will sooner or later cause chaos and also is a plain waste of time. If your boss wants to have it his way - let him. But keep pointing out whatever you think may cause trouble. If he still insists, give him a nice 'I told you so' whenever it really does go wrong.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock and me -
My company is currently working on a new project. I am basically the lead programmer. However, I have my boss (also a programmer) supervising me. I have recently looked into some design principles and design patterns. My boss has not (but is working on it)... So now we have the following situation, I want to make flexible and reusable software, while my boss wants to be able to make new classes and implementations quick and easy (but using a layered application and Entity Framework 4)... This has resulted in me making a generic class that goes with multiple generic interfaces that could handle any class that implements at least one of those interfaces (but every class needs its own implementation)... And my boss undoing most of my work (no more interfaces) and making use of Entity SQL giving every class the same basic functionality (no matter if it uses this). My boss' approach requires passing strings etc. my approach was always strong-typed. Actually now that I think of it, my approach could possibly support my boss' approach while this does not go vice versa. I am not saying his approach is plain wrong, but let's just say it does not have my preference. Are we programming in different directions or what? :confused:
It's an OO world.
Didn't find that new job yet?
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
-
Didn't find that new job yet?
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
Did not start looking yet, to busy with studying at the moment. I might not even want one since I am at three minutes with bike from my work. The next best thing I can get would probably be an hour by car + half an hour traffic jam :laugh: 5 points for you for only saying it though! :thumbsup:
It's an OO world.
-
Fix the team issues first. Second:
Naerling wrote:
I want to make flexible and reusable software
Many horrible systems have been born from that statement. I've created a few myself. Don't write a single line of code for changes that aren't needed right now. Stick with simple objects and only add interfaces if the class needs it to make the code simpler and easier to understand.
Curvature of the Mind now with 3D
Thanks for the concern. I did make those interfaces because we needed them. The problem is that my boss does not find interfaces easier... He is all into base classes. So instead of using multiple interfaces he could implement or not (which was what I had made) he now made one base class with a dozen overridable methods X| We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
It's an OO world.
-
I would suggest you sit down with your boss and start defining the architecture of the system before you do any more coding. Unless you are both working on the same page, your app will end up a disaster.
I did a few weeks back, I was not taken seriously... Now that we started coding and I can show them the benefits of good design in practice they start to listen. Except now it is too late. They want that form finished a.s.a.p. :)
It's an OO world.
-
My company is currently working on a new project. I am basically the lead programmer. However, I have my boss (also a programmer) supervising me. I have recently looked into some design principles and design patterns. My boss has not (but is working on it)... So now we have the following situation, I want to make flexible and reusable software, while my boss wants to be able to make new classes and implementations quick and easy (but using a layered application and Entity Framework 4)... This has resulted in me making a generic class that goes with multiple generic interfaces that could handle any class that implements at least one of those interfaces (but every class needs its own implementation)... And my boss undoing most of my work (no more interfaces) and making use of Entity SQL giving every class the same basic functionality (no matter if it uses this). My boss' approach requires passing strings etc. my approach was always strong-typed. Actually now that I think of it, my approach could possibly support my boss' approach while this does not go vice versa. I am not saying his approach is plain wrong, but let's just say it does not have my preference. Are we programming in different directions or what? :confused:
It's an OO world.
Naerling wrote:
My boss' approach requires passing strings
Naerling wrote:
I am not saying his approach is plain wrong
I am. Does he think that interfaces and abstract classes are mutually exclusive? Very often, when writing a class for my library, I create an interface and then write an abstract class that implements it. It's the best of both worlds. Perhaps you can write the underlying framework and he can write the apps that use it? Getting the innards correct from the start will make maintenance a lot easier down the road. I've been fortunate that those times I've been involved in writing a system from the ground up, I've been the only one working on it.
-
Naerling wrote:
My boss' approach requires passing strings
Naerling wrote:
I am not saying his approach is plain wrong
I am. Does he think that interfaces and abstract classes are mutually exclusive? Very often, when writing a class for my library, I create an interface and then write an abstract class that implements it. It's the best of both worlds. Perhaps you can write the underlying framework and he can write the apps that use it? Getting the innards correct from the start will make maintenance a lot easier down the road. I've been fortunate that those times I've been involved in writing a system from the ground up, I've been the only one working on it.
Well... Actually I should explain the core of the problem. My boss has always been the 'senior' programmer at our company. It is a small company, so it is not that hard. I started programming there about 8 months ago now, without any prior programming experience (well, some scripting here and there). Without wanting to be cocky I can say that in those 8 months I have surpassed all the programmers at the company (at least as far as OO(D) thinking goes). So let's just say that in the land of the blind the one-eye is king (I consider myself one-eyed ;P ). How would you feel as senior programmer if a rookie like me went telling you what to do and how to do it? There is no way in hell I am going to write the underlying framework. And on top of that my other employers (I have 3 total) are afraid I will write code that no one understands and then go work at another company leaving them with software they do not understand (it has happened before at our company). Today was my day off, but I actually send a mail to my employer (the one that ruined my interfaces) telling him I did not like his 'solution' and that the exact same could actually have been achieved by my previous method without having all those extra methods you do not need and without excluding other solutions as well. He send me a mail back telling me that at least now he could omit 'alien code such as:'
' The 'bridge' is actually an adapter, the SomeEntity is the bridge...
' My boss has read about databridges though and wants to stick to that naming, simply because he 'wants to see that name'...
' SomeEntity Implements Interfaces(Of T1, T2) which should match the bridge's T1 and T2.
Dim bridge As New DataBridge(Of T1, T2)(New SomeEntity, connString)So you see the problem :D
It's an OO world.
-
I did a few weeks back, I was not taken seriously... Now that we started coding and I can show them the benefits of good design in practice they start to listen. Except now it is too late. They want that form finished a.s.a.p. :)
It's an OO world.
unfortunately that's the business world... they want everything done yesterday... :laugh:
-
Well... Actually I should explain the core of the problem. My boss has always been the 'senior' programmer at our company. It is a small company, so it is not that hard. I started programming there about 8 months ago now, without any prior programming experience (well, some scripting here and there). Without wanting to be cocky I can say that in those 8 months I have surpassed all the programmers at the company (at least as far as OO(D) thinking goes). So let's just say that in the land of the blind the one-eye is king (I consider myself one-eyed ;P ). How would you feel as senior programmer if a rookie like me went telling you what to do and how to do it? There is no way in hell I am going to write the underlying framework. And on top of that my other employers (I have 3 total) are afraid I will write code that no one understands and then go work at another company leaving them with software they do not understand (it has happened before at our company). Today was my day off, but I actually send a mail to my employer (the one that ruined my interfaces) telling him I did not like his 'solution' and that the exact same could actually have been achieved by my previous method without having all those extra methods you do not need and without excluding other solutions as well. He send me a mail back telling me that at least now he could omit 'alien code such as:'
' The 'bridge' is actually an adapter, the SomeEntity is the bridge...
' My boss has read about databridges though and wants to stick to that naming, simply because he 'wants to see that name'...
' SomeEntity Implements Interfaces(Of T1, T2) which should match the bridge's T1 and T2.
Dim bridge As New DataBridge(Of T1, T2)(New SomeEntity, connString)So you see the problem :D
It's an OO world.
truth is... the boss makes the decisions, whether good or bad, all you can do is make recommendations... he has to live with the consequences in the long run (although you may too)
-
I would suggest you sit down with your boss and start defining the architecture of the system before you do any more coding. Unless you are both working on the same page, your app will end up a disaster.
I work in a very RAD environment and can vouch for the need to properly architect a project. Unfortunately for me, everything needs done the day before yesterday and the time is never taken plan out a project.
-
Thanks for the concern. I did make those interfaces because we needed them. The problem is that my boss does not find interfaces easier... He is all into base classes. So instead of using multiple interfaces he could implement or not (which was what I had made) he now made one base class with a dozen overridable methods X| We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
It's an OO world.
Oh boy, why don't you tell him to write the whole application in a single class. Define Forms as internal classes, make all variables static/global and insert a global self-destruct button.
-
Fix the team issues first. Second:
Naerling wrote:
I want to make flexible and reusable software
Many horrible systems have been born from that statement. I've created a few myself. Don't write a single line of code for changes that aren't needed right now. Stick with simple objects and only add interfaces if the class needs it to make the code simpler and easier to understand.
Curvature of the Mind now with 3D
I couldn't agree more. But that depends. I've seen projects go downhill because all the unnecessary super uber architecture prevented the project from finishing on time. One of them has been there for 3 years and it's not finished. It should've taken over one year and it was planned to finish in 8 months. On the other hand, critical systems (take real-time banking systems for example), that have continuous evolution and scalability should have a very solid design from start. I haven't gotten there yet, but I always try to prepared myself for that when the day comes.
-
I couldn't agree more. But that depends. I've seen projects go downhill because all the unnecessary super uber architecture prevented the project from finishing on time. One of them has been there for 3 years and it's not finished. It should've taken over one year and it was planned to finish in 8 months. On the other hand, critical systems (take real-time banking systems for example), that have continuous evolution and scalability should have a very solid design from start. I haven't gotten there yet, but I always try to prepared myself for that when the day comes.
I think the same prinicples still apply. Start simple and add as little as possible each time you put the system into production. I've done high performance web services that are literally hammered with thosands of requests 24/7 with live updates to the servers, and having a flexable simple design was even more critical. Complicated systems are way to hard to troubleshoot when you run into an issue.
Curvature of the Mind now with 3D
-
I think the same prinicples still apply. Start simple and add as little as possible each time you put the system into production. I've done high performance web services that are literally hammered with thosands of requests 24/7 with live updates to the servers, and having a flexable simple design was even more critical. Complicated systems are way to hard to troubleshoot when you run into an issue.
Curvature of the Mind now with 3D
I agree with that, but to scale things that do not have a good design from start is very difficult. I don't mean create incredible design, just very flexible design that can be simple. This adds a little overhead of time, but it's worth it. On the worse case scenario, imagine a flat unlayered web site with no Entity classes defined. I've seen that, too simple and too bad. I had to scale it and it was very difficult. I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there.
