Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Definition:
CRUD - Create, Read, Update, Delete; The four basic functions of persistent storage. In the context of this question, specifically related to business applications.
I'll be honest, my goal when I began programming did not include being a lifetime CRUD programmer. Financial data is only so interesting for so long. And to me, that seems like the majority of programming gigs.
I'm still fairly fresh out of school, so any experience is still very beneficial, but eventually I want to move to something "less CRUD like." Currently, I have my eye on some machine control type work. However, I'm just not sure how to go in that direction.
So I want to get a feel for what other developers think about the topic.
Do you enjoy CRUD and why?
What have your experiences in CRUD been like?
How did you move from CRUD to non-CRUD work?
If you've moved, what do you like and hate?
If you've moved, what skills benefited/hastened the transition?
Edit:
I'm approaching CRUD with the attitude that I want to solve problems, not re-create the same form with different fields for a dozen different tables.
I don't think that there's really anyone who enjoys doing CRUD (well at least anyone sane). It's the most tedious part of web programming. My advice is to find or write a framework to automate this for you.
evolutility
django admin panel and django forms
However, if that's the majority of your work, you definitely should consider changing jobs.
Get a different job. Seriously, not all software development is developing business applications. Developing shipping software would make you much happier, I think. Try to find a job at a software company, and write some stuff that's going to ship to customers. Also, if you want to get into some of the low level hardware-style stuff, just start hacking away on some basic microcontrollers so you have at least some background with that.
Develop a framework to make CRUD creation easy in your line of work. Once you have done that, use the free time to improve it in terms of Usability, Security, Performance etc. That should keep your work interesting for a while.
I agree that CRUD's pretty boring. But I don't think it's the fact that it's financial data that makes it so. Perhaps you'd find that financial data a lot more interesting if, for example, it was streaming into a neural net based expert system you'd written to work out how best to invest it?
There's definitely an awful lot more to programming than CRUD. Find an aspect that interests you, and pursue it.
I am curious that no one mention task-based UI and CQRS here.
In fact, to answer your questions :
I don't enjoy CRUD...why ? see the following answers to your question
My experience of CRUD is that's a pain to write CRUD (full stack frameworks are a workaround at best I think), and often a pain for users as well
I move to non-CRUD work when I understand that building software is about giving a powerful tool for users, not a database editor with some business rules
I like to build software less coupled to full stack framework (Symfony2, ASP.NET & cie...), more fully object oriented, but I am more and more annoyed by RDBMS CRUD orientation, and more and more attracted by EventStore (Event Sourcing)
Let's get inspired by task based UI, CQRS and Event Sourcing (search Google, I do not have enough reputation to add more links...) => all together
However, I would like to be less opinionated to finish : there are some points that will not let you get out of CRUD. Some users love CRUD, they feel like in Excel...and also there are probably some applications for which CRUD fulfill all the needs...
CRUD - yes in the end we are storing, reading and updating data. But so what? That is just one part of the equation, at least in my world.
In business, data is essential, but it is the business logic and the decisions made from that data that is important. I have found it very rewarding to take raw data and use it to help business make decisions. We do that with business logic in our code, not to mention the endless ways of presenting that data in the presentation layer.
Yes in the end CRUD is involved, but it is much more than that, no?
Just my opinion.
Having a wide range of experience, my solution is to create my perfect product and start a business around it. I'm facing all sorts of interesting challenges, such as how to stream realtime data from an embedded device to a browser. This stuff gets my programming juices flowing and I have a list of important, fun features to add.
Dream up your perfect product domain, find some people who could benefit and ask them what problems they have. Once you pick up a common theme that interests you (mine was automation and power monitoring) start hacking. Of course for me it helps that my father has run the electronics company Technman for the last 30 years, and wants to create this product with me.
First, have you gone through most of what there is to know about persistent storage? It's worth figuring out how to practically apply database theory, etc. in your current job. Once you've been doing it for a few years and have it all figured out you should definitely think about expanding your horizons. I'd agree with you - unless you're building the DBMS itself - I find that the persistent storage part of the job gets to be fairly boring.
One of the best ways to get a job in a new area is to take a prototype of something relevant to the job to demonstrate at an interview. This is an incredibly powerful statement to make.
Embedded software is really my thing, but the market for this is slowly shrinking in North America and moving to the developing world, and it's a fairly specialized area to get started in.
It seems to me that the application space is still growing. Consider iPhone, J2ME, or Windows Mobile development for example. You can learn to do these on your own with a relatively small investment in equipment.
If you're not already doing this, there's also the web application space. Application server platforms like JBOSS and Glassfish are free and fairly easy to learn. Plus they provide a link back to the CRUD which you already know.
Yes, a lot of business software is CRUD. I used to work on that.
In machine control, part of that can be CRUD too. For example, logging sensor data and reporting it somewhere. Basically CRUD.
But I will admit - in machine control, it's mostly non-CRUD. You would probably enjoy doing something that actually makes an assembly line move, or builds cars, or makes motors spin at a certain speed. I know I do. At a financial institution, it's literally just numbers. Nothing "real" like a motor or a car.
Just about every program is going to have to create, read, update and delete some sort of data. In some systems this presents its' own challenges.
However most of the time reading and writing to databases is fairly easy (which is why they make databases). It is what you do with the data once you have it which is interesting, and generally unique to a business, and keeps you employed.
This article I agree with, basically a lot of programming is boring.
However if you are good and determined enough you will eventually get to do something interesting.
Find or write a way to do the CRUD portions of the applications faster. Do so, tell your manager you are done with your assigned tasks (make sure they ARE done; tested, documented, etc.), and ask what you should do next.
Just take a look to Django and move on to the interesting coding!!!
(Or RoR, or Grails, or whichever suit best to you, but CRUDS shouldn't be still being coded by hand from scratch)
Modern frameworks can do all the crud for you. Checkout the standalone GORM from the GRAILS project.
When I was an undergraduate, I changed my major from Electrical Engineering to Computer Science because I wanted to write video games. Later on, when I started working on business applications for real money, I learned that I simply enjoy solving problems with code.
You may be in the wrong profession.
In this economy, it might be hard for you to just get another job, but that doesn't mean you shouldn't try. Find some type of work you think you would enjoy, go learn it and look for job opportunities. It doesn't hurt to make some phone calls and go on a few interviews even if you think you're unlikely to get the job. Even better, you could figure out a way to start your own company.
Get into web-dev? Seriously the level of basic crud I have to do building web-apps is pretty low, even when there's a DB.
For CRUD of windows FORM based applications developed in c# .net
RocketFramework is the answer
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Having recently worked with a bunch of people (from two different companies) right out of school or with 1-2 years experience, I was initially quite impressed with their knowledge of the various industry buzz words and design patterns etc. Furthermore they each had a good understanding on OO design principle and use of interface.
To cut a long story short…. In just a few days of working with them I found that things were not as they appeared.
Let me define some terms I’ll use here
Knowledge – Something you learn either in school or book or on the Internet etc.
Experience – The amount of time you’ve been doing something
Skill – Only gained through experience. That is acquiring skill (over time) and knowing how to apply the knowledge you have
What I found was that even though they knew this stuff, they really didn’t know how to apply this knowledge. You’d have all these patterns waving in your face but any code they had to write of their own accord had basic flaws with it. They could tell you the virtues of a certain design pattern and could come up with somewhat of an implementation but could not recognize basic flaws in the design.
Of course I had my fair share of the “One who knows not that he knows not –Confucius”.
Each night I’d spend a lot of time re-iterating everything that was said during the day trying to understand who was saying what and why, trying to figure out what I could do by way of examples during training or code review. But frankly I was quite puzzled.
After about 2-3 weeks I started to figure it out.
Anyway, the questions first
1. Have you experience this sort of thing?
2. How did you (or do you) tackle this?
My conclusion was that either schools are doing a bad job or Google is their friend and they’re getting all this “knowledge” and think they know.
But I feel
In order to be able to recognize and appreciate good design one MUST write code that is well,… not so well designed. Struggle with it and then fix it to know the pain and therefore recognize good and bad design and appreciate it
Practice and Experience – you just can’t beat that. There is so much that experience (and the quality of experience) brings to the table that you just can’t match it with just knowledge or a little bit of experience.
Some other things I experienced:
“Why is this an interface and not a base class” – you’ll get all kinds of answers but none of them is the right reason.
Why this design pattern and not that, or forget design patterns for a minute and just design (they’re utterly lost – that’s when you see their real design coding skills)
Over engineering – don’t recognize it and can’t appreciate they it could be a maintenance nightmare as the system grows. I found this to be a big issue. It's as if everything has the potential to change. A simple process of sending an email has 3 classes in addition to the various classes the in the .NET framework you'd use to send an email.
Using all the new features in the framework or language just because (I’ve even seen this in some of Microsoft’s source code for a certain framework for which source code is available)
So 10 years from now, everyone writing code is writing it using all the fancy framework or language features using all the possible design patterns, such that “legacy” code is well written and well designed. Or is it? What do you think?
Does anyone else feel that 10 years from now we’ll just be shifting through a different kind of muck. Muck that’s scattered about in a dozen more code files then it used to be because now we’ve got classes and so called loosely coupled code but it’s just a different kind of mess and in fact harder to clean up?
Interesting deliberations. I have always felt that with time we are over engineering our systems with all the patterns flying around. An extra layer of abstraction means more failure in understanding in future. My personal approach is to keep things simple and only introduce complexity if it is required. Decouple if decoupling is required. Many of the design requirements do flow in systems because we blindly put in requirements document that it should be maintainable, reliable and all *able. It's also necessary to understand the degree in which we want these *ables and more importantly how they impact our budget and business values both in shorter and longer term.
One important aspect is always to keep a very tight focus on business requirements, at every stage, both in terms of functionality and budget.
I completely agree that the newer breed of developers appear to be very knowledgeable when it comes to design patterns and the latest buzzwords like hibernate, jason, nant, ajax etc. In the other hand I have found that even the best among them, those who can be considered star programmers appear to have limited understanding and knowledge of what is really happening under the hood.
I had a several conversations in the past with young guns who were viewing spring as a major innovation trying to convince them that what this framework is providing us through reflection consist the evolution of things like IDL, type libraries, COM and CORBA.
When it comes to design patterns and the terminology introduced by the gang of four, we all know that their proposed architectures have been used for decades before and a senior developer was using them almost intuitively without knowing the formal differences of a regular factory versus an abstract. There is no doubt of course that the formalization that was introduced by the movement of DP was beneficial for the industry although the recognition and successful implementation of patterns still (and probably always) rely in the experience and talent of the developer since this process is impossible to become a purely mechanical and deterministic.
An additional point I have to make regarding newcomers to the field of SD is their inclination to spread their skill set very horizontally, trying to cover as many technologies possible as opposed to deeply concentrate in a specific domain and master it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In short I'm creating a 2D mmorpg and unlike my last "mmo" I started developing I want to make sure that this one will scale well and work well when I want to add new in-game features or modify existing ones.
With my last attempt with an avatar chat within the first few thousand lines of code and just getting basic features added into the game I seen my code quality lowering and my ability to add new features or modify old ones was getting lower too as I added more features in. It turned into one big mess that some how ran, lol.
This time I really need to buckle down and find a design that will allow me to create a game framework that will be easy to add and remove features (aka things like playing mini-games within my world or a mail system or buddy list or a new public area with interactive items).
I'm thinking that maybe a component based approach MIGHT be what I'm looking for but I'm really not sure. I have read documents on mmorpg design and 2d game engine architecture but nothing really explained a way of designing a game framework that will basically let me "plug-in" new features into the main game.
Hope someone understands what I mean, any help is appreciated.
If you search for component-based systems within games, you will find something quite different to what you are actually asking for. And how best to do this is far from agreed upon just yet, anyway. So I wouldn't recommend doing that. What you're really talking about is not really anything specific to games, never mind MMOs. It's just the ability to write maintainable code which allows for extension and improvements, which was a problem for business software long before games-as-a-service became so popular and important.
I'd say that addressing this problem comes primarily from two things. Firstly, you need a good specification and a resulting design that makes an attempt to understand future requirements, so that the systems you write now are more easily extended when you come to that. No plug-in architecture can work well without a good idea of what exactly you hope to be plugging in. I'm not saying you need to draw up a 100-page design doc, but at the very least you should be brainstorming your ideas and plans and looking for common ground there, so that when you're coding feature A, you are writing it with Future feature B in mind.
Secondly, you need good software engineering principles which mean that your code is easy to work with and use. eg. Read up on the SOLID principles, and take some time to understand why these 5 ideas are useful. Code that follows those rules is a lot easier to twist to whatever future needs you have.
There is a third way to improve your code, but which isn't going to help you just yet: experience. Your code gets better the more you write and the more you learn about coding. It's possible (well, likely) that with an MMO you are biting off a lot more than you can chew. Even teams of qualified professionals end up with unmaintainable messes of code when attempting projects of that magnitude, so it's no surprise that you would, too. But they have messes of code that they managed to see to completion, and often that's what it's about, not about stopping and redesigning whenever the going gets tough.
Yes, I got what you want...
Basically, you will have to use classic OOP design, the same one that business software coders use...
You will first have to lay out the basic engine, that engine should have a "module loader" or a common OOP-style interface, then you either code modules to be loaded (like, as .dlls) or you code directly within your source code, using that mentioned OOP-style interface, and NEVER, EVER allow a module to depend on each other...
The communication, even inside your code, should be ALWAYS using a interface, never put "public" vars in your modules and use it somewhere else, otherwise you will end with a awfull and messy code.
But if you do it properly, you can do some really cool stuff (I for example, changed the entire game library (API that access video, mouse, keyboard, audio...) of my game, in the middle of development... I just needed to recode one file, that was the one that made the interface between logic, and game library...)
What you're thinking about is exactly what this article describes. It's a lovely way to build games as I have blogged about, and the article is an excellent resource to get your started.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I work at a web development shop so naturally we deal with user profiles. When dealing with one of our sites I noticed that there was no 'User' class, which struck me as odd since we certainly have users. Instead the site relies on interacting with DataRows (this is C#) returned through static methods with little to no instantiation. I asked my boss about creating a class for users and his response was that since the objects have to be rebuilt so much its often not worth it.
I am relatively new to web development and it does seem like a bit of a waste to have to instantiate objects each time the page is rebuilt but on the other hand I've always found object oriented programming to be useful. So I'm curious for some opinions, how much do you guys use OOP in web development?
The only time I don't use OOP is when:
I'm creating a simple project to test some logic. This usually leads to creating the right classes...
I'm using Classic ASP (been awhile, thank god).
I'm not programming.
edit
3+ years after posting the above; I'm appending a bit to my answer.
OOP is great and allows us a tremendous amount of flexibility for having multiple systems interacting with the same data / logic. However, there is certainly a situation in which you wouldn't want to bother loading up a lot of objects.. Namely, when you are simply pulling data for tabular display.
Querying a database and getting a simple record set back that is immediately emitted to the browser usually doesn't need OOP involved. As a matter of fact you might want to sidestep OOP completely as tabular data usually involves a roll up of other information (sums of child records) and you normally don't want to pull more data from the database than what you are actually using. ie. if you are only showing the name and email you probably don't want to grab the user name as that is just wasted cycles.
Now, putting information into a DB usually involves making sure that certain business logic is followed. For example that the username follows certain rules. In those situations leveraging an OOP style keeps things a bit more encapsulated and easily transferred between systems.
So, looking at the specific example: I wouldn't bother with more than handing a datatable to a repeater when pulling data; but I would have a user class for when I'm going to create a new one or operate on that user to make sure the business rules are properly followed.
One question: does the data need to be coupled with function/method calls? If not, OOP is not necessary.
Your best approach might be to find an empty whiteboard, create a high level model using Object Oriented Design, then with Functional Design, then with Procedural. You might surprise yourself (and others) with the results. The same language can be used in vastly different ways depending on the project. As mentioned by #wj. OOP is just a paradigm, don't be afraid to step outside of your comfort zone and design using a different paradigm.
Taking time to design using different paradigms will also help you when you approach your boss to discuss why you should or should not use the current paradigm. Most bosses will appreciate that you spent the time to research before approaching them with an idea -- this isn't to say they'll accept your idea, but being knowledgable going in will potentially get you a few extra minutes of his/her attention.
IMHO (don't take this personally), "Object Oriented Programming" has fallen with the likes of "Web 2.0" -- a buzzword of sorts, which is unfortunate; you now see developers forcing OOP where it would be better suited to use FP or PP.
The best professional advice I can give is to design (high level at first, then dive down) in multiple paradigms (do your best not to be biased -- keep an open mind) and decide which one best addresses the way your application works. In my 15 years experience, 75+% of the time I find OOP to be unnecessary, although my current project is strictly OOP.
A more important/relevant question would be, "Does Object Oriented Design have a place in my current web development?"
Although objects make it easier for some programmers to develop, I've read the perfect example of how to build an entire website without OOP. Not once ounce. Check out the last page in a 20 page series entitled Clean PHP:
http://okmaya.com/clean-php/clean-php-step-20/
Super easy to follow, clean way of building an entire website. No confusing OOP, no super nested folder, no crazy spaghetti code to follow for hours... Just simple, clean, and well laid out functions that do EVERYTHING you need, without the use of OOP. And this example has everything from login/registration credentials, an admin section (CMS), even database fixtures to get you started, a search function that uses mapquest API to do zip code / lat-long lookups... I mean it has EVERYTHING for a core project, or website.
Why bother with OOP? Clean, and properly structured procedural code is great!
On the topic of OOP. I remember another fad that everyone thought it was cool, and everyone did it, but then found out that smoking gave you a whole bunch of problems.
Stick to the simple, stick to what you know. Be an expert in PHP and you never have to depend on a framework again. Don't get me started with OOP MVC Frameworks. Interpreted languages for the web were never meant to be OOP. OOP just adds another layer of complexity. Stop being lazy. Use your PHP, and learn how to freakin program!
On the other hand, I can see how making games on a console can be difficult without OOP. But then again, it's apples an oranges. Console games keep their objects in memory until the game exits, or object is destroyed from within game. Think about it... Why do they have a loading bar in front of every level? Now, imagine a web page that has to show you a loading bar every time it loads because it has to create objects from a database. SLLOOOOOOWWWWW central! And once you navigate away from this page, you have to start all over again.
Web pages are applications within themselves. It's like rebuilding your drag racer each time you go to the starting line, only to take it apart at the finish line. WTFridge? Seriously? Hey, super geniuses who think OOP is sooo cool... Keep your damn OOP out of my websites!
Just saying, this is from my 10+ years experience with web development, you know when we used to code pages in HTML, one by one?
OOP is nothing more than a programming paradigm !! but his importance is that hi is THE actual paradigm in use implying that all modern knowledge and best practices in software engineering will be expressed following this style of programming ...
A good example in your case (web development) is the Core J2EE Patterns.
(source: sun.com)
Of course it does. You (and more so your boss) say "rebuilding" like it's a huge chore.
What you mean by "rebuilding" is running the program. Tell your boss that OOP in general is stupid because even in a desktop environment every time somebody runs a piece of software the objects need to be rebuilt so it's not even worth it.
Boss's comment is useless. The .net framework consists of objects and nothing else. A "response" is an object, even in "classic ASP" - why would people have implemented it if that were resource ineffective?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
Improve this question
First a little about myself. I am not an experienced software engineer, architect or developer. I have done mostly small ASP and ASP.NET projects in C# for the last 5 years. I am pretty good with HTML and JavaScript. These projects were done when I had free time from my other duties which were not related to software development. I have now been moved into a software developer position. The company I work for is not a software development firm.
I am now working on a Silverlight LOB application with WCF and Entity Framework. I have been given little specifications for this project, just the 'make an application like X, only simpler so we don't have to pay for it', my boss doesn't check on my progress as often as I think he should, the project manager(a co-worker) will stop by now and then but we never discuss the specs, architecture, UI or business rules. I am mostly just asked when I think it will be done. I have had to learn Silverlight, WCF and Entity Framework to work on this project which is not a problem as I really enjoy working with these technologies. The problem is I am the only one in the company that knows anything about these and have no mentor/boss to discuss the problems and how they could be solved. I have been able to seek out one interested party in the company that has at least given me a list of some of the requirements.
I can't believe this is how software development should be done. I think the project managers should offer guidance and keep a closer eye on what is being done to prevent going in the wrong direction(but how can they in my situation since the don't know the technologies!).
Should I feel this way or am I way off base?
Thanks for listening.
What you describe is certainty not optimal, but it's extremely common, particularly in smaller shops. Some people find it rewarding to work in that kind of environment. It's not what the software engineering books teach, but that's why there are so many software engineering books.
If you want to continue working in this environment, you're going to have to supply all the discipline you rightly recognize as missing yourself. Write up a spec. Build a schedule. Share these with your management. Hold yourself to deadlines.
Share your concerns with your management; don't be shy about that. Chances are, they recognize the situation. Your boss doesn't check your progress? Publish your progress to him. Show him where you need to get to, how far along you are, and what's blocking you.
It'll be chaotic, no doubt, but you'll learn a lot.
Every organization is different. If they are operating in this capacity then you should adapt and make the best of the situation. It's either happening because that's how things are done and they are aware of it, or they don't know the wiser or don't want to invest to improve the process of delivering strategic/tactical projects.
In a perfect world everyone would have a robust Quality Methodology in place which would provide a framework for Project delivery and systems implementation. It's just not a reality.
Here are some tips to help you operate more effectively:
Identify your sponsors (the people who own the product) and determine the high level benefits and driving objectives of the business problem they seek to solve
Identify your stakeholders (who has influence and who has interest) and get them to communicate their needs as much as possible
Involve both sponsors and stakeholders in the process as much as possible or as much as they want
Capture what requirements you can from them through written form (email)
Provide opportunities for them to gain visibility into the delivery and to provide feedback
Your project will likely fail from your boss point of view. Because i'm sure you developing program not suitable for him. But you don't feel guilty. It's your boss' pain.('because you are good programmer). Sorry for so dark post :-).
The role of the project manager is not to know the technology, but they definitely should have a finger on the pulse of the project, so to speak. The real project management job is not to control the project, but rather to enable it. Either way, from your description, looks like yours isn't doing such a great job at it.
The other extreme is a process-heavy organization where meetings and committees decide everything, and all the real communication, if it exists at all, happens through side channels.
The ideal world lies somewhere in between.
Your project manager should not be too concerned with how you're doing things. Since they have no qualifications, the best they can do is connect you with someone who does. When they can't verify that you're building the thing right, they should at the very least ensure you're building the right thing. Even if it's for internal use, you still have a customer, and no communication with the customer spells bad news to me. :)
If your PM is not concerned about the issue, you could try to do something yourself. For example, ask the PM to connect you with a would-be end user of the application. Extract bits of your application and give them to the user to play with -- just make sure the bits you give them don't look or feel too finished.
If you can't change things, take this as a learning experience. Make sure next time you're up for a project, you know the things that went wrong last time, and try to mitigate them from the start.
And finally, if your bosses tell you this is a "more agile way" of working, punch them in the face. Agile is, or should be, synonymous with discipline, not complete lack thereof.
Good luck!
It is a hard situation. Only you can really determine the best way to proceed. However, I do think that the concern with the schedule and concurrent lack of documentation (requirements, expectations, use-case scenario documentation, etc) is a train-wreck waiting to happen. Even the sharpest and most experienced dev-teams suffer from the same problems.
The "when will it be done?" questions are best mitigated by regularly providing small partially functional builds that you can use to get useful information out of the moving target that is your customer. It is amazing how much communication can occur when somebody (your boss/customer/end-user) can actually "play with" something in front of them and reconsider what they really want.
I believe this situation is quite common. I had this, too, at my previous job. Here the bet is on the fact that you are already independent and well-versed in your business. I think you should tell your manager how you feel about this.
They should change something after hearing your opinion about this situation. Because if you do something wrong and the manager does not notice it, the company can lose a lot of money and time.
But it’s also not worth constantly waiting for someone to guide you and check your work. In any case, your workflow should have self-management.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When you are deciding on what methodology or process to use for your project, should you take into account the human factors? If there is any resistance to things, do you go with the flow or force people to change?
For example, say you want to push for pair programming but the team members resist to working in that mode (or show dislikes), what would you do? Make them get used to it, try to convince them to do it or go with the flow and let them do what they like?
The human factor is the most important one.
If you consider nothing else, consider the culture and proclivities of the group.
People who want a process to fail will succeed. It's far easier to alter process than to alter people.
First try to reason, you may be wrong:
If you have resistance to certain things, you can usually give your points for why you think it's good, and hear their points for why they think it is bad, and come to some common grounds.
You should never force people into doing something against their will, but instead try to convince them based on your logical reasoning. Many times you will see reasons from them that changes your point of view.
If your developer is too afraid to voice their opinion, then you should make them feel comfortable with giving their opinion. If they are still reluctant, then you should consider new developers.
Foot in the door principle:
If you want to try some new concept that neither you nor they have experience in, say pair programming, then you can ask them to try it for 1-2 weeks and then you can sit together again after this trial period and assess the effectiveness. I think most people will find it perfectly reasonable to try something new if they have no experience in it, if it is for the purpose of finding out the method's effectiveness, and if it is only for a trial period.
If after this trial period, the thing you were testing was successful, then your developer will be more open to the idea.
Don't change them, find someone who fits:
If you are 100% for some way of doing things, and your developer is 100% against it, and he won't try it and has no logical reason why, instead of trying to change him you're better off finding a developer that will fit into your way of doing things.
If they are 100% against what you want to change, you have to make a decision. Is the developer themselves more important to you, or is the process that you want to change more important.
If you force someone into something they don't want to do, they will find a way to make your method fail.
Yes. Your development process needs to be humane. That said, there are better and worse development practices and you should strive to use the better practices. The best methodologies understand both human strengths and weaknesses and have practices that promote the former and compensate for the latter.
For example, most agile processes put a high value on trusting developers to do the right thing -- to work hard and value quality. They allow developers to have significant input into the process and into the product. This takes advantage of the human quality of rising to expectations. On the other hand, humans have trouble managing too much complexity at one time, so agile practices insist on breaking things down into manageable chunks.
On the other hand, we know that people don't like to do things that don't directly add value to their work. Agile practices, recognizing the value of things like unit testing, insist on this however and require the developer to conform to it despite the initial reluctance. Using TDD compensates for this somewhat by giving real value to developing tests -- you do them first and let them guide the design. It's a bit of the carrot and stick approach to get developers over the initial reluctance to the point where they can experience the value of the method and buy into it on their own.
Adapting the Process
The key to developing a good process with your people lies in adapting the process to the amount of ceremony that you need or want. We use the RUP where I work and one of the central goals of the RUP is to tailor the amount of ceremony in your process to fit your project and the personnel.
For instance, small projects require far less ceremony and tool support. As well, people new to a process need time to adapt. It's best not to flood them with information and let them adapt at their own pace.
Show Me the Money!
To get people to buy into a new process is to let them make a mistake (or present an example form the past) and then show them how the process could have helped prevent the mistake. Try and draw a direct line to show how the process will help them improve the way they work.
For instance: if people are resistant to automating builds and running tests automatically then the next time they release a fix for something that broke a piece of code that was already working use that opportunity to illustrate that an automated test would have caught the error before it got released, saving everyone time and money.
Automation
To ensure people can adapt to a process is to remove as much human intervention from them as you can. Automate builds, tests, reporting as much as possible using information that is automatically captured.
How this helps support process is by removing the "nag" factor. Many people resist new process because they figure it means more work for them to do or extra work that produces little result in the end. By automating existing tasks and gathering data from them you get a lot of benefit without increasing any individual developers workload.
A classic example is continuous integration. Continuous Integration tools like CruiseControl, TeamCity or Hudson can work with version control repositories to extract latest versions of source code, build that code, execute and archive test results and package stuff for deployment. This requires no extra effort on the part of the developer but you get a lot of extra "process" in return. You now know how good your source code is, you can distribute it easily and you can catch bugs earlier.