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
There are lots of texts on how to plan software projects (with user stories, etc), but they usually assume you have a large budget, liberal timeframes and/or a real dev team available. While they sound fantastic, they never seem to account for solo devs working on a short deadline.
There is also a lot of talk about test-based methodologies where you write a test case for every method before you implement it, but I feel that these are difficult to impossible to apply if your software is GUI-focused (e.g. (server-side) web programming or Flash/ActionScript).
Although I try to make heavy use of refactoring to improve my code whenever I have finished a section of it, last minute hacks and additions tend to make this incredibly frustrating and I often feel that there should be a way I can utilise at least some of the planning theory that's apparently meant to help large dev teams and developers of software libraries first and foremost.
What is The Right Way to go about writing small-ish applications as a solo dev and how do you prevent last minute changes from making your code worse?
There is no "Right Way" unfortunately, however, there are a lot of better ways. I think there is no real distinction between small and large projects - the same kind of things need to happen, it's just the depth of those things that changes.
In your situation - working to a short deadline, preventing last minute problems - the same old tried and true methods are going to work:
Use source control effectively, develop last minute changes in a separate branch so you can drop them easily if required.
Test, test, test. If your tests cover the intent of what you were trying to achieve properly then last-minute changes can be measured.
I suspect you need to look seriously at some different types of testing and tools - there are plenty around that will help you manage these issues.
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
I can see the time employed in maintaining lots of microservices with functionality not independent from each other. Clients, queues, routers...a lot of stuff that maybe is not totally needed for attending the needs of conceptually simple projects. What is the downside of merging several microservices in a single monolith? If the project itself is the only consumer of most of its microservices, I think that partitioning a large app is just wasting time for the sake of following a supposedly good practise in an scenario in which does not fit.
Microservices provide for set of guide lines that help you build applications which can scale easily, which are more available and which allows your team to bring around changes really fast.
Having said that, it does not really closes the gate on monoliths or any other guidelines that you want to follow while building stuff.
There will be cases when building a monolith will indeed be a better option.
Say you are starting with some thing new, and you domain knowledge is not good. It will become really hard to break your application into services. In depth understanding of the domain is required to break services into effective smaller independent chunks.
Second could be you are doing a POC or MVP (with plans to test waters) then perhaps you can build everything as one.
With microservices, like I said you get scale, availability, maintainability and speed to make changes. There will be projects where these are not really a concern, and if they are not you can keep away from it.
Lastly, with microservices, you need to have a solid dev ops. you need to have CI/CD pipelines, you need to have monitoring, centralised logging etc, because trust me you will need it to debug stuff. It is indeed big investment and you should think what you are getting into and why you are getting into.
You should not be using it just because every one else is.
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 years ago.
Improve this question
I came to a successful project with 4 years old, it is already in the production.
The problem is that, the project is not documented anymore, it depends on 2 senior developers only, they know the system, they test, they handle change of requests..
I need to know what is the best practice, or what are the main steps that I have to do in order to document all the modules starting from high level design through component analysis & design, code comments, till the configuration management.
The traditional project management processes don't give me a clear idea of how to take the control back of a an old project.
Thanks.
Senior developers will easilly get bothered if you make them write docummentation all day long so you may lose them at the end.
I would hire a technical writer / junior developer if I were you and give him or her this as a first task. I would also make him or her work closelly with the senior guys, without taking too much from their time (like aggregating questions and have a one hour session dailly or something like that).
It will probably hurt in the beginning but if properly executed should prove a good choice at the end.
Note: The level of cooperation between your senior guys and the new guy that will be doing the documentation may vary depending on some internal "political" things like if the developers feel threatened by the fact that you are trying to make them less critical to the project, how overwhealming the new guy / gal is to them and so on. So answer those questions before going for it.
Once again - it is my personal opinion on the given topic and its success will definatelly depend on various factors. So you should decide if it is a good way to go or not.
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
I understand that it is better to discover requirements through iterative approaches in Agile, however I often hear of people rejecting projects on the basis that they are given up-front requirements.
Why is this the case? Why can't up-front requirements just be taken as-is, e.g. just added to a product backlog and then prioritized and implemented?
There's nothing wrong with up-front requirements. In fact it helps to know where you're heading before you set sail!
Agile is a lot about being able to be adaptable, so that should requirements change you're not locked into something you don't want.
The kind of up front requirements that would cause a developer to think twice about a project, would be those which indicate that the client are likely to be a nightmare to work with:
an obsession with one particular, unsuitable technology or presentation style
insisting on 'security' with glaringly obvious vulnerabilities
In an agile project, it's good to show a client the current state of the partially working system at an early stage, and get feedback, using this information to help design the subsequent parts of the system. If a client is too fixed on ideas of the final product then they might not be able to give useful feedback at this stage, and the final product may be not as good as it could have been.
This something that can be quite problematic with Agile. Some teams will use it as an excuse to not have a plan as they want to be 'adaptable'. Requirements can help to focus on the software architecture, which is something else that is not always given much focus in some Agile teams. It is points like these that lead me to believe that Agile should just be principles but not a methodology. Digital Animal wrote an interesting article about how Agile can be used in such a way that it stops being effective. For some teams, it is better to learn from what is great about Agile and use it to build a methodology that works for them. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=CZcb6f
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I am looking for some kind of solution to take care of development scheduling for web applications. How does the big guys in the industry handle this?
Is it all about SVN and bug trackers for them?
I'm not doing web develoment myself, but I assume that the approach for web development is exactly the same as for other big developments (which my team IS doing). In that case, the following tips might help:
Use version management (SVN, ...)
Be agile (this is also resembled by the following points)
Make a mixed team (developers, testers, designer, functional responsibles, ...) that all work as an integrated team on the same subject. Make sure the whole team communicates.
Make everyone responsible for the whole project. Never blame individuals if things go wrong.
Be sure the whole team knows the status of the project: where are we, what should still be done, ... Make everything visual by sticking graphs and sheets to your office wall.
Keep the time between 'raised questions or raised problems' and the answer or solution short. E.g. if a bug is found, log it immediately and try to solve it as soon as possible.
Develop incrementally. Don't develop for several months and then start testing, but make sure you have a working copy every day.
Split development/design/... tasks in smaller tasks that can be developed incrementally (see previous point) and in a minimal amount of time (a day or a few days).
Automate tests as much as possible.
Use continuous integration (where the tests are run at every commit in the version management system)
As a manager, support your team.
Focus
Shield the people of the team from all kind of problems not directly related to the project (e.g. PC problems, printer problems, ...). Choose a 'scrum manager' that solves all these annoying problems for the team.
Demonstrate the results at regular intervals to your customer, your boss, ...
Give a reception if an important milestone is reached.
There are probably many more tips. Therefore, read a good book about managing software development. There is probably no essential difference between web development and other software develoments.
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
Which is a good Project Managment Method to Develop a Website?
XP? The Waterfall Model?
Anything but waterfall....
But keep in mind that saying you are agile and being really agile are two different things.
For agile to really work over an extended period one has to also be doing several technical things well.
http://ayende.com/Blog/archive/2010/02/20/nice-process-but-what-about-the-engineering-bits.aspx
http://davybrion.com/blog/2010/02/youll-never-get-sustainable-progress-for-free/
Agile/XP would be best.
Waterfall would be the worst choice in my opinion.
It depends on who the customer is. If you are your own customer, then definately Agile.
If your aren't your own customer then you will have to negotiate with your customer on your development method. If your customer wants a fixed bid project and a hard deadline, then you will be best served by the waterfall method.
If your customer is willing to be an active participant in the development process and doesn't have a hard deadline and fixed budget then you could do Agile/XP.
It always depends on the type of the website you are developing, how many developers you got, what is the timeline, expectation for delivery time. But definitely Agile or prototype-iterative method will work fine for website development. To complete the development in different phases, and enhancing in the chucks, as an when identifying the strong and weak areas.
As well you can check the factors like target audience, maximum used sectors of the site and prioritize the development of those pieces first.
Always consider to go with standard framework, that will make life easier in long run with the future developments.
I find that waterfall fits some web site projects fairly well. Get the requirements, wireframe a design, do the graphic design, convert the graphic designs to HTML/CSS/JS, then fill out the content of the site. Client signs off at each stage. If the site is large the last stage ("fill out content") is probably more work than all the preceding ones and you'll want to use iterative methodologies for it, not waterfall.
Waterfall tends to not fit web applications very well. Those are software, treat them as such.
Use waterfall! But:
Set duration of the project to 1 month.
Then repeat this project until customer is happy!