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 am the sole software developer in a company and I answer directly to the owner of the company. We also use the services of an outside developer. The owner isn't a developer but 'wrote software in qbasic' many years ago. He has reasonable abilities to spec projects. The outside developer doesn't answer directly to me, and my boss is really a micro-manager and wants to keep it that way.
The outside developer likes to use layers of abstraction (frameworks and wrapper classes), but has implemented them when I was stuck on months-long projects. When I return, the boss now wonders why it is so time consuming for me to do maintenance on projects (including one that I initial wrote from scratch).
I'm unhappy reverse engineering his code and I'm having trouble articulating the fact that I must learn a complete different interface from code that looks alot different than what I wrote in the first place. At the same time, the outside developer looks like a hero. Suggestions on how to articulate this to a technical/yet non-technical boss and how to put a lid on this happening in the future?
At the risk of sounding patronising, be careful that it is not just your perception of what you think your boss is thinking, which may be quite far from the reality.
Your boss may be wanting you to explain the situation not because he does not trust you, doubts your competency, or wishes to belittle you; but rather to understand where the difficulties are so that he can make an informed business decision on whether it is worth you reverse engineering this code- or perhaps be better to leave it as is and move on, on different aspects of the project.
Being honest and explaining that you have limited experience with these frameworks/wrapper classes may "buy" you time to not only learn these frameworks (which will hopefully benefit you greatly in the future), but may also mean that you are appearing to embracing and extend upon the other developers code, which is good team spirit if nothing else.
At very least, ask your boss to ask you if there are aspects of your explanation that he needs further clarification on. Keeping nice clear lines of communication will help everybody move forward faster.
Hope that helps!
Gav
I don't know if you can get away with this with your boss.. I could with mine, but not everyone can.
First, this has to be done respectfully, and the suggestion I'm about to give should be within the scope of a longer discussion. When it comes to the point of having to explain the difficulty of working with this developer's code...
Type up a paragraph in English, have someone type up the same sentence in some language your boss does not know. (Chinese, Spanish, Klingon, whatever.) Give your boss a (language) - to - English dictionary and explain that while you are technically capable of translating this outside developer's code into something useful, it takes time, just like it would take him time to translate from (language) to English using the dictionary.
Perhaps this would work best in the context of trying to establish standards for working with outside agents and potential new hires.
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 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 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
Some friends of mine came up with an idea for a web application which we (so far) think could be great. I made the analysis and all the early stages of the development process and I'm about to start the coding. I'm talking about something that is barely a mid-level project, so I consider one developer (myself) should be enough.
The thing is that we are trying to assign roles to each one of us so we can be focused on our duties and have clear our responsibilities within the team. We are a crew of four people, three of us (my friends) are business people who would do the marketing, customer relationship, management and accounting stuff and I'm basically the developer. I have in mind to get them involved into the development process by giving them documentation to write and use them as testers, all of that besides the management duties they have.
Perhaps someone out there have been in the same situation, so I would appreciate if the experience is shared so we can effectively give ourselves positions in the project based on what I explained above. Which are the essential roles or the optimal team layout so the idea can be developed successfully? The question is not strictly about programming, but it's related to build a software entrepreneurship beyond the code, that is something that I'm sure plenty of us are looking.
Any help is really appreciated! Regards.
I think you're on the right track. What I tend to do is think about responsibilities in terms of "functional" vs "technical" and go from there. "Functional" responsibilities and requirements reflect the customer, the user, the stakeholders and are usually technology agnostic. "Technical" responsibilities and requirements translate the functional items into architectures, platforms, technical relationships, coding languages, etc.
Here are some possible functional roles your partners can fill to support your development role:
Project Manager: Ultimately responsible for timelines, budgets, and delivery of projects / sprints and product delivery.
Business Analysts: Collect customer requirements for the software. This role usually requires subject matter and market expertise or access to such expertise. They ultimately write the functional specs that your technical specs will be derived from.
Product Manager: This role compliments the marketing efforts by ensuring that first and all future iterations of the product are meeting market and customer needs. They have full responsibility for bridging that gap between functional and technical.
I think what you mentioned about also using them to write documentation and test is a great idea, as it will help them understand the development time and effort required from your job, and allow them to speak intelligently to the more technical aspects of the product, even if they are not techies themselves.
They could also play a big role in helping construct the user experience, by storyboarding and wire-framing.
Good luck!
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
Where I work, we have small teams of 2 - 5 people. As a dev lead, what are some things that you've implemented which makes your team stand out from the others? Meaning, it makes the others teams say, "that's cool" or "why didn't we think of that". Just some thinking out of the box that made your team extremely efficient.
Automated unit testing and an automated build system (like CruiseControl)
Hawaiian shirt day
Why compete with other teams, the company goal should be a common one.
We roughly have two teams (one working on the 'off the shelf' product and one working for tailor made solutions). But we are used to help each other alot. And in my opinion that is the way it should be.
First and foremost -- we get things done on time that meet the done criteria. That's the best thing to do, in my opinion :)
We're currently doing unit and functional test automated with CC.NET. QA loves us for it. But, I'm looking for things such as that.
Do in-company presentations on general topics that the other teams might be interested in, but are not directly related to their work (otherwise they are supposed to know more than you about those issues).
Volunteer to do inside projects that benefit everyone. (e.g. Stylecop introduction into the codebase, geek lunch every week, and similar)
We standardize only the build process. We don't make our SKILLED developers use skills that are dictated to them. We let them code however they want, with an editor and command line, with an IDE, with a hammer and chisel if they want. They are only constrained by the build process. Everyone is subject to the same build, in our case an ant script.
Developers like and perform in our group because of the freedom. Other groups who constrain their developers can't understand how we do it.
Write good code?
Edit: Of course this is totally wrong, the actual answer should be:
Write bad code.
I dont agree that its a company Goal. Because finally each person is looking for his or her own self.
Its important for a team to stand out. Reason being manyfold.
To stand out the team must be able to present themselves and the team lead has to take the responsibility. Its not enough to develop good code these days but also to be able to present it
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Does anyone know of any software or a good way for developers to build up a knowledge base of business rules that are built in to the software for help desk to use?
We already have a helpdesk software but we are not looking to replace this.
A wiki is definitely the way to go. Processes change, sometimes frequently, and in a fast-paced environment like a help desk a tool that allows quick, easy access and management of that type of content is extremely important to allow people to do their jobs effectively.
One of the greatest benefits I've found is the heiarchical sturcture of many wikis, allowing employees to find the correct content from a number of different customer angles.
Can you be more specific?
This may fall under "policies and procedures" management software. Here are some:
http://www.softscout.com/software/Human-Resources/Policy-and-Procedures.html
I'd like to find one that's more wiki-like or easier to integrate into a a website serving as a more general company knowlege base.
I would recommend a wiki wiht a "Wiki Gardener" role- someone who cleans up the duplicate entries and sorts.
Wiki technology with a Rich Text Editor option would useful if your Support Desk are not totally technical.
Having some structure is imperative, developing something in any Wiki that makes sense to the general editing populace, and has a low threshold to get from reading to editing. You will also possibly need a migration strategy for taking hundereds of little notes into something more readable and searchable.