Subversion Key Points Condensed

As with most of us when trying to master Subversion, you might be slightly overwhelmed with the amount of info you have to learn to become a “Subversion Guru” (not just basic use which is plenty to handle, but also build, branch, etc.) wouldn’t it be nice if someone made sort of a condensed version of the key points from this book and other sources for  a nice quick reference?  Well, that’s what I’ve been doing just because the book is so damn long and there’s just so much to learn about subversion and I need to become a “Lead” on this in a short amount of time.  I use this as sort of a long cheat sheet / learning doc for myself as I become a Subversion master.  It gathers key points that I felt were important and I laid them out into bullet points.  The docs are just too long and ramble too much into paragraphs in my opinion.

While my shortened key points doc (which also contains my own notes or information from other sources) is not completely done, feel free to use by downloading it Subversion Key Points Condensed.  I will also add my build process in here once I figure out how I’m going to do that for our team.  The doc behind this link will be continually updated till I feel it’s enough for me to get by.

I’d also be curious to know your team’s build process from tagging to push including branches you have set up for different stages in development.

posted @ Sunday, May 17, 2009 10:46 PM | Feedback (1)  

Summary of Agile

Share this post :

I’ve been reading up on a lot of Architecture and Design Pattern books including MVC and much more as I am working on a huge project lately to redesign the presentation via ASP.NET MVC for our public website. 

Agile is something that a lot of businesses abuse that have no clue what it means and they should never be using the word until they wake up and read about what it actual means to be “Agile” and truly change their environment and get their organization to buy into true Agile processes.  They have no right to throw this term around when a lot of companies carelessly claim that they are an Agile development group when they are completely opposite.  They think Agile is an excuse and weapon to use against their development team in order to “Code & Run” thus disregarding quality of code and ultimately hurting the business due to the rush rush mentality pushed from top down.  I’d like to take a moment to quickly list what Agile is along with my own side notes based on some books I’ve read already.

So any fool can tell you that you can’t have quality and good working code never happens when top down does not give adequate time for:

• Testing including Unit, Usability, and QA
• Learning, allowing developers to sink in what they’re coding or researching while coding
• Attention and time to apply good development practices and time to be able to think before you code.  Time to apply principals and really be able to think about SOLID, DRY, etc.  When you code & run, this goes out the door because all you’re thinking about is the idiot manager breathing down your neck

What is Agile?  Here’s a list of some bullet points I’ve accumulated from various references:

Book:  “Microsoft .NET Architecting Applications for the Enterprise” by Dino Esposito

• Emphasizes the incremental building of the software
  • Dave’s side note: rather than code & run cowboy who tries to fit EVERYTHING into one date…fail 
• The project goes through a series of iterations that include design, coding, and testing
• Each iteration produces a deliverable but incomplete version of the system. 
• During an iteration, you focus on a single requirement at a time and implement it
• At each iteration, the team enters design changes and adds new functions until the full set of specifications are met
• Agile Methods focus on people and communicating rather than on software building and processes
• Change and refactoring are key in an agile methodology
• User feedback is valued over planning
• Feedback is driven by regular tests and frequent releases of the software
• Working software is the primary measure of progress
  • Dave’s side Note: Note that this says “Working”.  This means frequent releases but code that has been built well and tested often and has a very low number of bugs.  Working means not only bugs but it works for the customer based on their expectations and that the software was built based upon their frequent feedback & usability tests.  Code that was not produced in a code & run mentality where the stakeholders value more than just results.  Stakeholders (top down) understand that unit testing, usability testing, QA testing are critical, and allow for the Leads to build this into the iterations
• Project starts and only a few requirements are known because you know for a fact that many more will show up between now and the end
  • This is not an issue because you take a subset of the existing requirements that you know you’re able to implement in a single iteration
• At the end of an iteration you deliver a working piece of software.  It might be incomplete but it works
• If something changes in the requirements or proves to be wrong, you refactor it
• The team is highly skilled
  • Dave’s side Note: Agile will not work for teams who have only low-end developers.  While some people say you have to have all high-end, I also disagree.  As long as they are solid in OOP, and care about using good development practices recognized in the community then you’ll be ok.  It’s the slop coders that will not do ok on your team or those coders who do not care about SOLID or DRY.  You’re not asking for perfection but the developers on an Agile team must be aware of and try their best to code clean testable code
• Customers and developers work together daily
  • Dave’s side Note: while this might be what agile is, this is a bit too much in my opinion.  Every day is a little overboard especially when developers are expected to hit an iteration
• Results are immediate and visible
  • Dave’s side Note: This means you always have something that is able to run on your test server even though you’re local copy may not be able to run as you’re working on it.  Implementing continuous integration helps to ensure that you have a solution that you can run at a given moments notice so  you can show to your customer the state of the feature at any time
• Iterations are often measured in weeks.  Typically two weeks
• Agile methodologies is a blanket term.  When you refer to an agile methodology, you aren’t talking very precisely.  Which methodology do you mean, actually?
  • For example, Scrum is a popular agile methodology.  It is aimed at managing projects and works very well with Agile development

Book:  “Practices of an Agile Developer” by Venkat Subramaniam & Andy Hunt

• Creating software is not a linear process or deterministic process.  Software development is more like surfing.  It’s dynamic and ever-changing.  It’s unpredictable and risky.
• Iterations are small repetitive cycles
• If you have problems with absenteeism, slackers, or outright saboteurs, this is probably not the approach for you
• Automate Acceptance Testing
• When developing code always choose readability over convenience
• Listen to Users
  • Every complaint by your customer holds a truth
• Use unit testing to provide instant feedback and to make your code robust
• Fixed Prices are Broken Promises
  • to a customer’s view this is completely reasonable but in reality a software project is subject to all the simple mistakes plus fundamental changes to the requirements
  • Given the inherent volatility and irreproducibility of software projects, coming up with a fixed price ahead of time pretty much guarantees a broken promise in the works
  • Ask yourself can we make some sort of deal?
    • Dave’s side Note: meaning for example if the task is too large or can’t be fit into the iteration, can we swap features so that we can still keep on track with the iteration?
• Justify Technology Use
  • Does it really solve the problem?
  • Will you be tied to this technology?
  • What about maintenance costs?
• You don’t leave testing to the end of the month
• Integrate early, integrate often
• Automate deployment early
  • if it works on your development server fine, but it needs to work in the production environment too
  • you need to be able to deploy your application onto the target machines in a reliable and repeatable way
• It’s ok to have ego but not if it’s unhealthy and negatively affects the team
• Let your customers make the critical business decisions based on options you give them
  • However they shouldn’t make all the decisions.  For those you don’t agree with, discuss them early
• Question until you understand
  • Don’t accept what you’re told at face value.  Keep questioning until you understand the root of the issue
• Small reachable goals keep everyone moving forward
• A regular rhythm that’s too intense will burn the team out
• Criticize ideas, not people
• Provide useful error messages
• Review code
• Be a mentor
• Allow people to figure it out
• Don’t over engineer, keep it simple
  • managing to get 17 of the GOF patterns into code is NOT being agile.  You’ve making your code too complex for the team and over emphasizing patterns
• Invest in your team’s learning
• Keep your balance.  Know that you can’t be an expert at everything
• Ask yourself whether you’re projecting too much of the old attitudes and approaches onto the new.  Unlearning is important.  What you knew worked a long time ago could be making your code or team ineffective. 
• Do not make people defensive on the team by your actions
• Do not blame, but work as a team to fix the problem
• Quick Fixes become quicksand
  • projects seem to attract a lot of time pressure.  Pressure that encourages you to take ill-advised shortcuts
• You don’t stop gathering requirements and feedback as you being to code
• Do not take shortcuts in your code
• Make changes as soon as you realize that things are headed in the wrong direction
• Always start with and tackle the most difficult problems first
• Pay attention to your attitude and the team’s.  A professional attitude focuses on positive outcomes for the project and team
• Software is never really “done”
• Tackle small problems when they remain small and explore the unknown before you invest too much money into it
• Be prepared to admit you got it wrong as soon as you discover the truth
• Ask the users what features are essential to make the product usable.  Don’t be distracted by all the nice features you might possibly have
• If there is not enough time in each iteration, then the tasks are too large or the iteration is too short
• Timesheets are intended for payroll and accounting and are not really meant to measure progress of work in software projects
  • They rarely represent the reality of work completed and therefore aren’t useful for project planning, estimation, or measuring performance.  Odds are it probably took longer than you anticipated.  Adjust your estimate based on experience.  If you underestimated a two-day task and it took six, you were short by a factor of 3.  Therefore multiply your estimate by 3.
• Measure progress by keeping the road ahead very visible.  Don’t kid yourself or your team with irrelevant metrics. 
  • The best way to do this is by using a backlog.  A backlog is just a list of tasks that still need to be completed.  When a task is completed, it’s removed from the backlog.  With a backlog, you always know the next most important thing on which to work.
• As new tasks are introduced, they are prioritized and added to the backlog

As I find more sources I’ll update this post and bullet point those as well going forward.

posted @ Sunday, May 17, 2009 8:57 PM | Feedback (3)