My manager currently believes that design is important, but not crucial for all but the most ambitious projects. It is my opinion that he thinks it is important to design, but not necessary and that big ball of mud programming can 'get the job done.'
What are some methods of discussing (topics, examples, etc) the importance of planning and design? I'm looking for things to do, say, or change that are within my power as 'code peon', so answers such as, hire another senior, fire weak members, etc. aren't very helpful to me.
Alternatively, is he right and I'm the one who should rethink my approach to development?
Essentially, our team consists of three strong developers, a few weak developers, and some people who, in my opinion, shouldn't even be in the field.
We have no dedicated architect, so the three strongest developers who act as unofficial team leads are somewhat looked to in order to design all but the most trivial of projects, unless the manager decides that 'ball of mud' is good enough. They are also responsible for their own (some times multiple) ongoing projects while mentoring and helping others. This leads to an acceptable, but full work-load from week to week on these individuals.
My point of describing the background is three-fold for this team:
The manager is an intelligent, though stubborn man who will listen to reason, but you must convince him thoroughly of the 'why'.
There is not enough time currently to inject any training methods that take away from daily duties of development and no one is likely to be hired anytime soon to alleviate some burden.
The only current method of creating better code with the individuals that are available on the team is by designing their projects for them and guiding them through the process of implementation, thus, we have this question.
I wanted to consolidate what I've taken from the answers so far; Some of these are intuitive, but not something most think about from day-to-day (imo):
Managers like metrics. True, but as M. Fowler believes (and I agree) productivity and quality is immeasurable. Besides, I don't have the means to accumulate the metrics as 'peon'. (thanks Novelocrat & duffymo).
There will always be a mix of talent, you must present a learning environment We are supportive in this in attitude, but I think other tools are needed to create this environment. (thanks duffymo).
Engage the weak, alleviate the workload of the strong In addition (as a result of?) to presenting the learning environment, engage the weaker developers in strengthening their design skills by giving them small, atomic parts of the project to design (with approval) themselves. This removes responsibility from the stronger devs, teaches the weaker, and may be an acceptable solution for the manager as it doesn't take time from his higher paid employees. (thanks duffymo & Tom Anderson)
Perhaps you could buy him a good book.
E.g. Software Project Survival Guide which I've started to read. It has some nice checklists that might be compelling—e.g. score yourself by this checklist on whether your project has the essentials for success.
Try Googling "software project best practices" and see what you get. E.g. "Best practices for software development projects". Invariably they will support your goal.
Background: All of my experience in developing software and managing projects has been related to applications (not counting a few trivial hacked-together websites here and there). Process-wise, I typically start off templating Rapid Development and the Software Project Survival Guide and then tweaking the plan to suit the needs, resources, etc. of the project. This has worked well for me.
Soon I'm going to start building a website to supplement an application that I've been working on that will require a lot more planning and foreknowledge than sites I've made previously (think something akin to Newgrounds). There will be 2 other developers on the project, and we're all on separate continents (only reason I mention this is to dissuade answers involving "small team doesn't need any kind of formal process").
My question is, what changes should I anticipate when moving from the planning of an application to the planning of a website (though the site will involve web applications as well. using django.)?
I typically distinguish between web sites and web applications. If the site is mostly content and a UI to find and manipulate the content, then I consider that to be a web site.
If, on the other hand, you actually do things on the site, or affect other parts of the world, then that's an application that happens to be delivered over the web, hence a "web application" to my mind.
I would largely develop a web application the same way as any other: best practices, separation of concerns, automated unit tests if not test-driven development, etc. The only place you should be seeing a difference is in the nature of the UI.
Depending on your platform, you may not have the same tools available for testing the actual Web UI as you'd be used to for testing a desktop UI. To my mind, if you've thoroughly covered all the non-UI code, then this is not such a big deal.
I am currently a college student and I don't feel that any of my classes have touched on the Software Development Life Cycle (SDLC) nearly enough.
I've been interning a company for a few years and I've been learning about SDLC from the internship, but I wanted to poll the crowd so I can branch out from that.
What SLDC resources (books, websites, magazines, newsletters, etc.) do you use?
Could anyone please suggest a software process suitable to the work our team?
You can view us mainly as a team of freelancers each waiting for a task to be handed to him. Sometimes if a big module is required 2 or 3 developers start working together on it, but that's when things starts going bad as we lack a well defined software process to adhere too.
So We are looking for a software process that can help us organize our work and provide an acceptable output.
You say you're mainly Juniors. So, learn to walk before you try to run. I suggest you try a staged delivery model. And I also suggest you try reading this book: http://www.amazon.com/Software-Project-Survival-Guide-Practices/dp/1572316217
I seem to have a problem, I have a growing business to run but I end up spending a lot of time doing the programming myself and sharing some load with the one programmer I have under me. I had a team of 3 but 2 left cos I obviously was not very good at planning/delegating tasks and was more a hands-on kind of programmer. I preferred to have control and would find it really boring to plan out the requirements in writing and give it to them...I would just verbally give them the instructions and things didn't seem to work out very well that way.
I need your suggestions. I have no experience of working in a development company, so not really sure how to go about the process of developing our web applications without me having to do too much detailed planning in the programming. I always have a basic idea of what needs to be done, I'd ideally like someone who can put that idea down into a detailed plan and program or manage the programmers. Are there people like that who perform such functions and if so, what are they called [Also, is it feasible to hire such a person with just one programmer and then perhaps hire more later]? Also, I've found that all our projects are constantly delayed cos we don't set any deadlines (we develop for ourselves), how to avoid that, do programmers work well with deadlines?
I just want to be able to supervise all areas of the business and not just focus on development, which has been taking a lot of my time.
If you only have one developer, it seems silly to hire a dedicated project manager; everyone at a company that small must fill multiple roles for the company to work well.
For the next developer you hire, it would really help if they have the ability to lead a development team; it doesn't sound like you have that ability yet, and you may (or may not) have time to learn on the fly. If you can find a developer who can do this for you, that's efficient.
In the meanwhile, I might buy a copy of McConnell's "Software Project Survival Guide", and give it a read. It explains the basics of managing software projects, and does a good job of it while being easy to read.
For setting deadlines, it usually works to have developers work with managers to set reasonable deadlines that everyone is aware of and agrees to. If they're set by the developers, the schedule will be very, very long; if they're set entirely by management, you get a lot of frustrated developers.
Immediately, I'd start writing high-level requirements ("we need a better login system"), and prioritize them into various levels:
With that list, you can figure out better where to spend your time, and what to delegate. If you delegate something, it's occasionally going to come back not-as-you-envisioned; alternatively, you have to do one or more of the following to keep your vision on track:
I have been a software developer for a while but was not interested in the above topics, currently I am put in the position of wanting to learn more about them but don't have a clue where to begin.
I have done task estimations and I can do decent ones, but have little/none experience in the field of budget/product pricing and would want to learn more.
Do you have any suggestions of good resources that I could look up in order to learn more (eg. books, blogs, ...)
This need arised while talking to a friend about management and he brought up management terms that I wasn't aware of (eg. KPI, ...)
Project Management with Respect to Time and Budget
There are a couple of books you should check out:
Joel Spolsky posted a quick estimation technique.
I found this software project management blog.
I attended a Project Management class (as part of a Masters in Technical Management) and they used the Project Management: A Systems Approach to Planning, Scheduling, and Controlling book. It is a very dry book but has a ton of very useful information; luckily our professors were pretty good at their job (one topic that helped me a lot was dealing with conflict -- but that has little to do with estimation and budget which your question seems to focus on).
I think that the book, Micro-ISV: From Vision to Reality, discusses that. Basically, you should already have established a relationship with some people that represent your customer base and who have cobbled together a crappy solution. If your software represents an elegant solution that fixes their needs, you ask them 1) would you use this if it was free? If they say yes, then you ask them 2) Would you pay a million dollars for it? At which point they'll say, no way, the most I would pay would be $500 (or whatever) -- that's one way to price your product. :)
If you are going to be managing people, read these books: