Work methods
Published: 2020-11-14 23:08:10

Today I am going to talk about systems of work methodologies within software engineering. I think that it is important to go about work, whatever type it might be, with a plan. Whether its sports or construction the most effective work areas have a good plan behind them.

In our coding too we will have plans. When you think about it coding, is like setting up a work site. You need to first think about what you are doing, what your goals are and how you are going to get to those goals. You will separate concerns and make things happen piece by piece. Whether you are building a full application or just trying to solve an algorithm, a plan is an important part of getting success.

So it makes sense then, that while we are working in software development, there would be general plans and makeups of how we go about our work. The plans can be constructed to work towards specific goals or they can be more general. Today I will talk about a couple different methodologies that I have recently and not so recently learned about. 

In my limited experience the most common method is AGILE. The key point to agile methodology, as far as I understand it, is the breaking up of pieces of a project to eventually put back together to make a result. One of the good parts of this style is that you are quite efficient. Because you are working on bits of things at a time, you lower your risk to the whole. Also because of this you can see things that might be better or worse for your project earlier. Agile work methods often involve lots of communication, not just between the devs, but with the users as well. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/jhk269ucsk2ev78h7po1.jpg)

A form of agile methodology that I have heard a lot of people talk about as well is called scrum. Within scrum, there is a lot of time boxing and regularity. You use the system more than the system uses you. There will generally be sprints and meetings. During meetings, you will talk about things like that you are planning to do, what you are stuck on and what you have accomplished. During the sprints, you code and do work. 

Personally I have worked with scrum, and I found it to be pretty fun and cooperative. In the morning we would meet up and talk about what we might be stuck on and what we were planning to do in the day. At first this was a bit annoying, because I would just want to get to what I needed to do, but I found later that it helped me gather my thoughts a bit to talk about it. Also it was nice to know where everyone else was at and what they were working on / struggling with. It made it very open to ask for or give help. Then we would work in sprints and keep having breaks and meetings. I think it worked well, because you wouldnt get too lost in a problem and you are constantly refreshing your mind. 

There is another fairly common type of agile methodology. It is called feature driven development. Working in a feature driven development team would focus very much on the function of whatever we are building ( or the feature =) ). The consideration of the model of the project is very important and the speed of development is encouraged. The process will generally go with a domain object model, then the though of features will be addressed. Then the team would plan and finally code.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/dnpn6dl9mqdiovjd2su5.GIF)