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 6 years ago.
Improve this question
What, in your opinion (although I would highly appreciate articles / books on related issues), should be the the level of the programmers knowledge of the domain?
(This related question didn't quite answer my question / had a reference to something I can use)
If programmers were domain experts, they would not be programmers. :-)
For example, I do a lot of software development for archaeologists. If I knew as much about archaeology as the users I work for, I would be digging and surveying in the field rather than programming. Which makes no sense.
Having said this, I think that programmers need to be knowledgeable about the domain, and as much as possible, but without losing track of priorities.
If you need domain expertise, bring a domain expert into the team.
Yes and no.
As Kyle pointed out, programmers are often changing domains on every project and this pretty much precludes you becoming an "expert" in any given domain. On the other hand, you need to understand the problem well enough to a) craft a solution, and b) test that it actually solves the problem at hand.
One reason for not claiming domain knowledge is so that your customers are forced to take ownership of this part of the project. The best way I have fouond of forcing them is to require a clear overall description of the project (no more than a couple pages long) plus a ton of User Stories ... written by the users. You can lead them through the process of how to write US's, but they will not truly own the end solution unless they were intimately involved in creating it.
Having US's and using them both for design and testing puts project ownership where it ultimately belongs -- in the hands of the users of the system.
As a consultant I am constantly (every 6 to 12 months) changing domains. Though I can never proclaim to be a true expert by the time I finish a project, the more domain knowledge I acquire, the more value I can add the project.
If you don't understand the problem domain, you shouldn't be coding a solution.
You don't have to be an expert, but you cannot be ignorant of the key ideas.
As a FORTRAN expert, you won't make any progress coding an FFT unless you have
some background in signal processing, and understand why an FFT is necessary,
and know a variety of implementations.
That depends on how related to the domain the specific job they're doing is. In team context, I can imagine that the lead programmer and some others benefit from a bit of domain knowledge while others in the team don't need it.
Banking/financial applications
Networking/wireless/telecom
Mobile Applications
Web/storage/enterprise/Numerous others..
If by "domain" you mean your area of work, yes you should strive to understand everything related to your area of work. How far into other areas that extends is another question.
programmer is like people who can interface "other people" with computer by creating software, and better understanding of the domain where you're working for would help the communication between the problem and the "other people" thus would make you a better programmer.
but the problem domain is often very wide and deep, you can expect everyone to be expert at programming and expert at another field, for example you can expect great scientist or physicians to be expert at programming to solve his problem when creating space-ship because programming is not his main concern, so with programmer, but programmer or scientist who can talk to each other is the best fit
Even if you change projects and with them domains frequently, domain specific know how and experience in one sector (or branch of trade) will be always a plus.
I look at this as "WHAT" versus "WHY". As in What is the business requirement versus Why is the requirement such as it is. A junior programmer only needs to understand the WHATs of a project. An analyst needs to understand both. In my opinion and my professional status, to stop being a developer and to become a software engineer, you need to add analyst to your skill set.
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 5 years ago.
Improve this question
I am a long time agile advocated but one of the things that bothers me about Agile is that a lot of agile practitioners, especially the younger ones, have thrown out or are missing a whole lot of good (non Scrum, non XP) practices. Alistair Cockburn's style of writing Use Cases springs to mind; orthogonal arrays (pairwise testing) is another.
I read mostly Agile related books and articles and work with mostly Agile folk ... is there anything I'm missing?
It might be interesting in 5-10 years time to see how maintainable these systems are when nobody wrote down why a particular decision was made and all the people involved have left.
is there anything I'm missing?
Yes, I think a lot, but only if you are interested in Softawre Development Processes.
I like this paraphrase:
Each project should be as agile as possible but not more agile.
Not every project can be agile... but I think 80%+ can.
I see Agile as "car of the year". It is very well suited for most of the people, but if you need/want something special, for example car able to speed 300KM/H or car able to carry 20 tons of goods you need something else.
There is also so many cases when one may want something else than "car of the year" that requires a book to write them down :-) I recommend you Agility and Discipline Made Easy: Practices from OpenUP and RUP. In this book you'll find many "missing parts" very well illustrated. The key to understanding is that Agility is only a (requested) property of software development process which sometimes cannot be achieved. The book describes several Key Development Principles (which are basis for RUP) and explains which level of "ceremony" and "iterativeness" follows from using them on different levels of adoption.
An example
Practice: Automate change management and change propagation
In your project you may require very advanced and strict change management and decide to "Automate change management and change propagation" by implementing custom or re-configuring existing tools and by using Change and Control Board.
Effect: This most probably increase level of "ceremony" in your project.
(...) have thrown out or are missing a whole lot of good (non Scrum, non XP) practices.
Scrum is not prescriptive, it's up to you to choose how to do things. In other words, nothing forces you to use User Stories for example (even if User Stories work for lots of teams, there is no consensus) so feel free to use (light) use-cases if you think they are more appropriate in your context. To illustrate this, Jeff Sutherland reported he would never use User Stories again for PDA device projects (they use some kind of "light specifications" in his current company). And the same applies for testing, use whatever works for you. To summarize, if you find XP not flexible enough, use something else... and inspect and adapt.
Iterative development.
In practice, agile teams may do iterations (or anything for that matter, agile is a kind of "true scotsman"), but agile processes don't require or define iterative development sufficiently.
Take RUP, for example - clumsy and bloated, it does compile a few good methods for long-term development that agile misses.
On a general note, agile is a way to steer clear of problems: how to avoid long term planning, how to keep teams small, tasks short, customers involved, etc. It works more often than not, but sometimes you have to face and solve problems: how to reach strict deadline, make big team work, achieve distant and complex goals, make customer refine requirements. That's when one needs to look beyond agile.
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 have sprint task in Scrum, where do you put how you want to program something? For example, say I am making a tetris game and I want to build the part of the game that tracks the current score and a high score table. I have my feature, my user story and my task, but now I want to talk about how to design it.
Is that design something that is recorded on the sprint somewhere as to how to do that or is that just somethign the programmer figures out. Do you put do task x use database such and such, create these columns, etc.? If not, do you record that at all? Is that what trac is for? I don't mean too high level design.
I touched on it here: Where in the scrum process is programming architecture discussed?
but my current question is later in the project after the infrastructure. I'm speaking more about the middle now. The actual typing in the code. Some said they decide along the way, some team-leads. Is this is even documented anywhere except in the code itself with docs and comments?
edit: does your boss just say, okay, you do this part, I don't care how?
Thank you.
There can be architectural requirements in addition to user-specified requirements that can muddy this a bit. Thus, one could have a, "You will use MVP on this," that does limit the design a bit.
In my current project, aside from requirements from outside the team, the programmer just figures it out is our standard operating procedure. This can mean crazy things can be done and re-worked later on as not everyone will code something so that the rest of the team can easily use it and change it.
Code, comments and docs cover 99% of where coding details would be found. What's left, if one assumes that wikis are part of docs?
Scrum says absolutely nothing about programming tasks. Up to you to work that out...
Scrum doesn't necessarily have anything explicitly to do with programming - you can use it to organise magazine publication, church administration, museum exhibitions... it's a management technique not explicitly a way of managing software development.
If you do extreme programming inside scrum, you just break your user stories for the iteration down into task cards, pair up and do them.
When I submit tasks to my programming team, the description usually takes the shape of a demo, a description on how the feature is shown in order to be reviewed.
How the task will be implemented is decided when we evaluate the task. The team members split the task in smaller items. If a design is necessary, the team will have to discuss it before being able to split it. If the design is too complex to be done inside this meeting, we will simply create a design task, agile/scrum doesn't force how this should be done (in a wiki, in a doc, in your mind, on a napkin, your choice) aside for saying as little documentation as possible. In most case the design is decided on a spot, after a bit of debate, and the resulting smaller tasks are the description of how things will be done.
Also, sometimes the person doing it will make discoveries along the way that change the design and so, the way to work on it. We may then thrash some cards, make new ones. The key is to be flexible.
You do what you need to do. Avoid designing everything up front, but if there are things you already know will not change, then just capture them. However, corollary to YAGNI is that you don't try to capture too much too soon as the understanding of what is needed will likely change before someone gets to do it.
I think your question sounds more like you should be asking who, not when or where. The reason Agile projects succeed is that they understand that people are part of the process. Agile projects that fail seem to tend to favor doing things according to someone's idea of "the book" and not understanding the people and project they have. If you have one senior team lead and a bunch of junior developers, then maybe the senior should spend more of their time on such details (emphasis on maybe). If you have a bunch of seniors, then leaving these to the individual may be a better idea. I assume you don't have any cross-team considerations. If you do, then hashing out some of the details like DB schema might need to come early if multiple teams depend on it.
If you (as team member) feels the need to talk about design, to so some design brainstorming with other team members, then just do it. About the how, many teams will just use a whiteboard and brain juice for this and keep things lightweight which is a good practice IMHO.
Personally, I don't see much value in writing down every decision and detail in a formalized document, at least not in early project phases. Written documents are very hard to maintain and get deprecated pretty fast. So I tend to prefer face to face communication. Actually, written documents should only be created if they're really going to be used, and in a very short term. This can sound obvious but I've seen several projects very proud of their (obsolete) documentation but without any line of code. That's just ridiculous. In other words, write extensive documentation as late as possible, and only if someone value it (e.g. the product owner).
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
Let's say that a developer is interested in learning Scrum, but nobody else on the team is interested. I realize that Scrum is made for teams, and the process would have to be modified to fit a single person.
Is there any benefit to be gained by the developer trying Scrum, even if the team doesn't? If so, how would the process be modified to suit the situation?
I think there's benefit to be gained by any method that helps you develop goals, tasks, keep on top of work and deliver something often.
Your individual work-products would gain the same advantages that teams gain with scrum:
You'd get something done every {Sprint Iteration Period Here}, something you can hand off and say "This is now ready".
Your estimation technique will start to improve with reflection and retrospectives
You'll start to plan your day and make commitments to yourself about getting things done, so again your estimation of your capacity will increase
Retrospectives will formalize improvement of your personal work process. You'll start actively improving, removing and adapting to suit you and your individual needs.
You wouldn't be able to rely on other team members to help out, which is a bit annoying, and you wouldn't have a product owner, Scrum master or a backlog to pick tasks from. You may not even be in a position to make decisions on what to work on next. But I think the formal discipline and reflection is helpful for all craft practitioners, at all levels, alone or in groups.
And who knows, you might even inspire your team to Scrum it up once they see what great results you're getting.
I would suggest that you use Extreme Programming instead, as that works better for one programming than a decidely team-based process.
Then you can get the benefits of being more agile, but if your team is not agile then you will have some issues due to the use of a different paradigm.
For me, the biggest key was getting buy-in from my supervisor. It can be tough to try and have some sort of Sprint only to have it interupted multiple times (Supposedly XP teams handle this better, but I don't think any developer does.). Also, don't forget to include either power users (they could be testers) or members of other departments that could be used as Product Owners. I like to sit with other users and do a type of paired programming (OK they don't code) where I can ask questions while coding and do quick demos to get feedback. This helps when I'm struggling to create specs because those requesting the app are having a hard time telling me what they want.
Even if it's just you in the daily stand-up, it can be scrum.
If you compare yesterday's planned with actual and define today's plans -- without talking to other people -- that's still a kind of daily stand-up.
I'd say that what you're doing probably is scrum if you're following the daily-sprint-release cycles; even if there aren't a any other people to talk to each morning.
G'day,
For the best thing to come out of learning Scrum is the concept of involving the customer early and often. That way there are no nasty "that's actually not what we wanted" moments when you deliver to the customer after six months hard work.
HTH
cheers,
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 4 years ago.
Improve this question
I have long been of the opinion that the time and resources it would take to write a piece of malicious software, of whatever type, could better be spent on other things. However, as a developer I am constantly worried about the possible security flaws in systems I work on.
Of course I know about validating input, I understand fully how code and sql injection can work and obsessively sanitise against these risks. Also, whenever I am able, I bone up on new security risks with whatever resources are to hand (e.g. articles, whitepapers, presentations etc.) but I often feel I'm missing the point, maybe because most of my knowledge could well be classed as "new-fangled" (C#, MSSQL, PHP, some Python, a smattering of Ruby): the oldest language I know is Classic ASP.
Sometimes when I read about things like Cross Site Scripting and URL hijacking I read the articles upon which they are based but I feel like I'm not following 100%.
What are the best resources you know to get to grips with security concerns and really understand how they work? Could be anything, books, websites, other types of resource. I know I don't know enough about these issues so where could I go to learn more?
http://www.owasp.org/
Well, you could start with a recent post from Jeff:
Top 25 Most Dangerous Programming Mistakes and work your way forward from there.
Try James Whittaker's How to break software security
One Monkey,
The fact that you are asking the question means you are well on your way. The real issue is that so many don't ask, are not worried as you are.
One thing I would modify is change the thought that you know some security issues fully. There are some really devious little jerk-offs out there. I am of the opinion you are better off assuming they are smarter than you and so bolt things down as tight as possible. I find it is a better mindset.
Two resources you should look at:
XSS Cheat Sheet
A good example of SQL Injection
I must admit to being somewhat surprised at the lukewarm response to this query. Does this mean:
a) everyone else knew about OWASP and I'm way behind the curve?
b) everyone else is confident enough in the security of their code to not need a little help staying up to date?
c) no one else cares?
d) other?
I have found the reference to OWASP most helpful, so far I'm about to install some of their project software to see how it works, once I feel that I'm better off security wise for having a look at their site I'm marking that answer as accepted, unless something better comes in in the meanwhile.
http://www.securityfocus.com/ and the categorised mailing lists.
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'm in a new contract where they seem to have gone overboard with Agile, including hiring a consultant merely for facilitating Agile processes. Something he is instituting is a notion of "core hours" where we will all actually be in the same room together. Is this really what "core hours" constitutes? I ask because it's highly inconvenient to pick up my laptop and go to this shared location for half the day; I always thought "core hours" meant you were available, not necessarily in the same room, from 9:30 to 4, for instance.
Yes and no.
Core hours are the period(s) when all team members commit to working on the project (and not doing administrative stuff or other projects). For many teams, this will imply being in the same room, but with proper planning and the necessary infrastructure, the team can work well from different locations.
I think what you have is an extension of the "core hours" where you are. The idea of being in the shared location is that ad-hoc meetings could occur as well as possibly being within earshot of various discussions so that you can jump in if it is something where you think your opinion or knowledge would be useful, e.g. why was this coded like that? or why do we have this requirement? kind of thing.
I'd like to think that I'm up to date on the Agile world. In reality I am not. With that being said, I'm not so sure this is an agile concept but rather a convenient way for the team to collaborate. It sounds more like something out of Peopleware.
As goes with any team and trying something new, one, there will be resistance to change and two, the team should really have buy in to the new process and working methodology. The Agile consultant shouldn't just be barking orders of what you need to do. He should also be explaining and convincing you why this is a good thing. If you already think the company has gone "overboard" then I think something is wrong. Agile is a great way to work for a many (but not all) teams and shouldn't evoke a reaction like that
Having core hours makes sense so that there is an overlap for collaboration. Having people work in a more open space, maybe 4 people per large cube instead of 1 per small cube, also helps foster collaboration. At work I can just spin my chair around and there are 2 people right there who can help me out or answer questions. However, trying to force something that is uncomfortable and inconvenient defeats the purpose.
I think it would be better to tear down the cubicle walls and rearrange the cubes to make the evirnonment more collaborative.
Slightly off topic but won't fit in a comment:
Agile is extremely disruptive of a programmers "Normal Practices". The word Agile means you are going to have to adapt to changes, I recommend you try to accept them and not fight, because one of adaptations is to cut out team members that cause disruptions in the team.
A consultant is virtually required for a smooth, quick transition.
If your consultant is doing it right, you should be much more unhappy than you seem. During those core hours, none of you should have your own computer--you should be sharing a group. If things are done right, you should be coding in a "Bullpen" without cube walls (facilitates pairing and general communication).
But there are various levels to Agile, and it's intended to be adaptable. Many programmers have a problem with pairing, so often it isn't forced, or is just recommended.
At any rate, it sounds like your consultant is taking it pretty easy on you guys. Try to drink the cool-aid and relax, it'll all be over soon.