Agile.

I have spent a lot of time trying to figure out what ‘Agile’ is. Back in the early/mid 2000s, after the tech bubble and before the great recession of 2008, there was a brief period of optimism and solidarity in software engineering. We learned a lot from the booming late 90s and from the bubble bursting in 2001. Aside from the economic turmoil there was also turmoil in the personal lives of engineers and developers.  120 hour work weeks, sleeping in the office, breakups, divorces. It was a lot like the gold rush out west in the 1800s, but instead of a material commodity it was information and access/sharing of that information that began really generating revenue and movement.  Along with individuals going gangbusters to get a piece of the information/technology pie, large companies became more excited or greedy about getting a piece of the pie or even a bigger piece of the pie. This lead to many companies rushing plans together that were not the most well thought out and squeezing every drop of production out of their employees.  California, being one of the first to go through a cycle like this, implemented their overtime law. This basically says that even if an employee is on salary, if they work over 40 hours they’re entitled to 1.5 X their pay per hour.  This was implemented because companies were hiring their employees and paying them a ‘good’ salary but then pushing them to work 3X as many hours and thus resulting in a pay cut in reality.

We Respond And Change

After living through and seeing all this happen through the 60s, 70s, 80s and then the 90s, a group of experience people got together and started….’Agile‘!  This is Agile…right here…on the next line…that’s it…read it and pay attention!

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

You may have read that and thought ‘where does that mention sprints?’, or ‘they didn’t mention the burn down chart!’…etc…etc.  That’s because those things have nothing to do with Agile at all.

I often hear people compare Agile with the Waterfall Model and that really doesn’t make a lot of sense. Agile is a philosophy and the Waterfall Model is a development cycle model. While in college, in my last year, I chatted with a professor about this difference and why I thought it was significant because there was a final version of the Waterfall Model that I thought would work pretty well.  In theory Royce’s Waterfall Model  could even be executed in an Agile environment. The Agile Manifesto is a set of values to be applied when working with humans and in realizing this I think those values are far more powerful than any development cycle or methodology that will ever exist.

We Practice

Try making the Agile Manifesto the first thing you read in the morning before you start working for 1 week.

Individuals and interactions over processes and tools

The next time you hear someone complaining about a process or tool ask them how they would fix it or update the tool.

Working software over comprehensive documentation

When people ask for documentation, make sure that there’s something out there to document.

Customer collaboration over contract negotiation

Work with your client/customer/boss/coworker to figure out what it really is we’re trying to accomplish instead of blindly doing something and then falling back on your contract/agreement when your product misses the mark.  Building better software/products means we have to own a project if we’re participating in it.

Responding to change over following a plan

If something isn’t working…stop…turn…go. None of us live long enough to waste time follow a plan we’ve proven doesn’t work.

Conclusion

Remembering that Agile is actually a set of values and not a methodology could really open up our eyes to improving our methodologies over time. We have been clinging to ‘Agile Methodologies’ too tightly and with that we have ignored one of the Agile principles, “Responding to change over following a plan”.  Let’s keep responding to change and valuing people and interactions over processes and tools to move forward in creating better software for people that can bring us to a better future as humans.

TL;DR;

Um, it’s not that long…just go back and read it 🙂

Advertisements
Agile.

What are Developer/Engineer skill sets?

This is the beginning of a multipart series of posts. While I know this won’t be perfect and people will probably have disagreements, I actually hope we can talk about it a little bit and maybe come to some standardization and unification.

Job definitions are hard, because in most cases working in the technology field, you will end up doing a lot of different things.

Today I want to investigate the title of “Web Developer“.

We have all probably heard of this title before and at first glance most will know what the person that holds that title does on a day to day basis. Or do we…

Let’s start out with what we probably agree on.

A “Web Developer” should be familiar with the core building blocks of websites and the best practices of implementing them.

  • HTML
  • CSS
  • Javascript

Keep in mind that there are many tools and ‘technologies’ built on these core languages and platforms. Things like jQuery, AngularJS, LESS, SASS, Bootstrap and so many more.

HTML

HTML’s responsibility is to define content and structure it in an organized way. You’ll here the term ‘semantic’ used with HTML/markup a lot.

‘semantic’ means “the study of meaning”.

Semantic HTML is subjective in some cases but there is a lot of content written in HTML everyday and there are many best practices for semantic markup.

Tim Berners Lee, and Paul Irish are big influences that come to mind.

CSS

CSS’s stands for “Cascading Style Sheets”. “Cascading” refers to the rules of how styling is applied to HTML and is really the power behind CSS. There are many thoughts behind CSS and how it should be applied and organized. So much so that there are transpilers that enforce or provide simpler access to more complex CSS features.

SASS is my personal preference right now. With CSS it’s important to know about the box model and default browser values for padding and margin to be able to create a consistent experience across multiple platforms. CSS is also where a lot of the “Responsive Design” decisions and management happen.

Eric Meyer is a huge influence on CSS and has contributed a lot of great best practices and design patterns.

Javascript

Javasript is the core of dynamic websites. Javascript is used for everything from countdown timers to handling complex data manipulation, games and analytics.  Javascript is downloaded by the browser just like images or any other content on your website. Then the browser runs that code inside its own environment.

Javascript is very powerful and also very complex. There are many libraries out there and many thoughts on best practices with javascript. It’s hard to find the right answer for the best way to do something, but a good way to tell is if the javascript is easy to read and understand what it’s doing then it’s probably a good sign.

Douglas Crockford and Addy Osmani have been really influential in the Javascript community.

 

Next Time…

I plan on this being at least a 1 of 4 part blog post. Next I’ll be covering the “Senior Web Developer” title, followed by “Software Engineer” and “Senior Software Engineer”.

Please feel free to discus and let me know what you think a “Web Developer” does! 🙂

What are Developer/Engineer skill sets?