Thoughts on Agile Development

I'm here talking about my thoughts on Agile Software Development, you can find the wikipedia article on the topic here.

The problem with developing a large program for a customer is that often times your needs can change from day to day. The customer may think he wants something  but a week later he realizes he wants a different but similar feature. If you have already spent a month modeling the infrastructure of the program you're writing to conform to the original request, this change of heart may rustle your jimmies, to say the least. But how can you avoid having a design for a project? Obviously when you're working on something so large, starting the design before you just jump into code can be very helpful. But how do you balance between design and changing needs?

Agile software development tries to walk the line between these two seemingly conflicting ideas. Using agile development means you get to interact with the customer more, write more of your program and less documentation, and be able to respond to changing customer needs with poise and not frustration. These are all good qualities, but planning certainly has good features as well. When you're working towards an end goal, you know exactly how you need to write things. Though you may not be as adaptive to change, you definitely will be more efficient with your end goal in mind.

Agile receives its fair share of criticism as well. It is written from a management standpoint, meaning some programmers will resent it, seeing it as unnecessary bureaucratic busy work. And this sometimes may be true. I, personally, think agile software development can be very useful given the correct context. Just like all things, I think it has its place, though this place isn't necessarily universal. I think I would have to work more with agile software development before I committed to too much of a judgment, but I will say that I have a healthy respect for agile software development, as I think it is always important to keep change in mind when working on any long term project, and it is especially important with software development when requirements can so easily change from day to day.

Project Timeline: 12 Weeks from Nothing to Changing the World

I'm here today talking about my project timeline. This is referring to the concept that I wrote about in my last couple of posts, check those out if you're interested. I'm going to be writing up the week by week timeline to start and finishing with a graphic with the most important milestones linked (the graphic will be posted tomorrow).

Because of the nature of this project (it's being done for a class) we have a set amount of time to get it all done. In this case, that time frame is 12 weeks. We go from just forming a group and learning the project to a fully fleshed out site in 3 months, so we need to have a decided budget of time so we can know if we're on track or if we get behind. This is important because if the project isn't finished by the end we have no more time to work on it, and our whole project is ruined.

Some things we are going to need to keep in mind for the project are the following:

Client meetings: Each week we, as a group, will have to meet with the clients for a half hour to talk about progress and changing demands.

Requirements: The site will have certain requirements that we have to meet, ideally we will have most of them done before the end and will not have to depend on finishing them in the last week. Also, these demands may be changing based on the client meetings and experience of the programmers with the project.

Modeling: We will need to get the site modeled before coding as to have a blueprint before working on it blindly.

Development: Obviously a lot of time will have to go to development of the site, coding and design, etc.

Release schedule: Will the site have early versions without all functionality ready for testing? If so this needs to be scheduled out

Testing: Time will need to be budgeted to test the site for bugs and design problems.

Deployment and Delivery: Mark times when the site will be delivered. This will have to be before the end of the twelve weeks, but will it be early?

Documentation: Time will have to be budgeted to document the process of our work on the site.

Marketing: The site will fail with no users. We need to market this to the right demographic and this will take time and energy, which needs to be budgeted.




For each week, I will budget 75 hours of time based on the assumption of 5 members of the group. This means the weekly half hour meeting will take 2.5 man hours as it is .5 hours for 5 people. (However, I will be budgeting 5 hours for these because even if the meeting only takes a half hour it is likely the group will end up discussing for longer)

Week 1:

Budget:
Introductions and learning each other's skill sets: 5 hours
Weekly client meeting - 5 hours
Concept and Basic Design: 20 hours
Basic skills acquisition (understanding AWS, learning HTML5, figuring out what algorithms, including Fourier transformation, are necessary, etc.): 40 hours
Setting up server: 5 hours

Goals for end of week:
Finish initial design blueprint for the site
Make final decision of framework and skills needed for site
Set up the AWS server


Week 2:

Budget:
Weekly client meeting: 5 hours
Design development, including planning out features very fully, and modeling site: 30 hours
Code development and documentation: 40 hours
          Basic framework for site in html5: 25 hours
          Back end and AWS: 15 hours


Goals for end of week:
Finish framework of site (not functional, but a bare bones of what we want it to look like)


Week 3: 

Budget:
Weekly client meeting: 5 hours
Sound file manipulation design, how we're going to save files and attach headers: 45 hours
Algorithm implementation: 20 hours
Documentation: 5 hours

Goals for end of week:
Have a better idea of how we're going to save sound files and how the algorithm will work


Week 4:

Budget:
Weekly client meeting: 5 hours
Sound file implementation programming and documentation: 50 hours
Algorithm implementation: 20 hours

Goals for end of week:
Have significant code for the implementation of recording or converting sound files to be compatible with site


Week 5:

Budget:
Weekly client meeting: 5 hours
Sound file implementation programming and documentation: 50 hours
Figure out how to manipulate lengths of files to change beat of songs uploaded: 20 hours

Goals for end of week:
Finish up the code for sound file manipulation, ready for implementation in week 6

Week 6:
Halfway mark

Budget:
Weekly client meeting: 5 hours
Implementation of sound code onto website: 25 hours
Working with site and AWS to make sure clients can upload files: 40 hours
Documentation: 5 hours

Goals for end of week:
Working prototype released
Will be able to upload files through the site
Will be able to manipulate files through site
Will be able to mash sound files through site


Week 7:

Budget:
Weekly client meeting: 5 hours
Front end touching up, making UI nicer: 35 hours
Back end reinforcing, bug fixing, making more robust: 30 hours
Documentation: 5 hours

Goals for end of week:
Website looks good, performs well


Week 8:

Budget:
Weekly client meeting: 5 hours
Bug testing, content creation and bug fixing: 50 hours
Marketing, and seeing market response: 15 hours
 Documentation: 5 hours

Goals for end of week:
Get a market response
Measure market response (positive/negative and why)



Week 9:

Budget:
Weekly client meeting: 5 hours
Adding new features based on market response: 50 hours
Continuing marketing: 15 hours
Documentation: 5 hours

Goals for end of week:
New features implemented


Week 10:

Budget:
Weekly client meeting: 5 hours
Finishing new feature implementation: 35 hours
Testing and bug fixing: 30 hours
Documentation: 5 hours

Goals for end of week:
Version 1 released
Full version with all features wanted
Should be relatively bug free
Go live with site to public


Week 11: 

Budget:
Weekly client meeting: 5 hours
Bug fixing from new release: 20 hours
Testing public response: 30 hours
Any additional features requested by client or users: 15 hours
Documentation: 5 hours

Goals:
Attempt to handle the amount of users on site
Fix any user problems in a timely manner


Week 12:

Budget:
Weekly client meeting: 5 hours
Touch up front end: 20 hours
Finish all back end and server code to make sure users have no problems: 30 hours
Testing and bug fixing: 15 hours
Documentation: 5 hours

Goals:
Final version released

Concept paragraph: Additional thoughts

There were a few things I was not very specific about in my previous post, and I'm here to address them today. For those interested in what I'm talking about, refer to my most previous post on here for more details.

While I do not want to change the idea of the site, I would like to specify a few things that I did not go into detail on. First, what platform will be used? Honestly, I don't have a lot of experience with a website like this. My initial thoughts are that I want to use HTML5 for the front end and app side of it. We can use AWS for storage of material so it can be accessed from anywhere. HTML5 is really slick and robust, and I think it will be good for what we are doing.
As far as funding goes, we will need some. Servers cost money, so the site will obviously take some funding beyond the programmers compensation. However, this is going to be a variable cost, based on the amount of traffic to the site. Initially, if we are using AWS and we are students, we will likely be able to get away without paying while we are still working on the site. Eventually, once we have a project ready to show, investors will hopefully chip in to get it up and running. Once we are established and have reached an acceptable user base, we can begin putting ads on the site. Also, the music created on the site will eventually be able to be downloaded for a small fee, which a percentage of will go to the site for every transaction. A percentage will also go to each artist who contributed to the song. This makes it so artists are incentivized to create more music and are more likely to want to use the platform for making their music.
These again, are initial ideas, but I felt it was important to go over some of this stuff before I continued with the project.

Proposal: Concept Paragraph

I'm here writing today about a concept for a project that I would like to work on for my software engineering class. This project will take up a semester of work for a team of people, and I'm hoping that others will want to join me in working on this.

There are plenty of socially uploaded media sites out there, but none that focus on the needs of bands. One thing that I've always thought was necessary was a site that could act as a banding together of musicians from around the world and allow them to work together through the internet. There are millions of musicians in the world, just waiting to be recognized or just wanting to express themselves. However, it is not easy to form a band with a person in another city, let alone another country. The internet lets us connect these people in a novel way. In my site, people can upload music they've recorded or record it fresh, and tag it with an instrument and their unique username. In this way, they can upload an guitar part, for example, that they have written and thought was very cool. In a different part of the world, a drummer may listen to this piece and make a drum part and attach his part to the guitar part, forming a duo but with each part being credited to its respective writer. People can sample each other's work without stealing it, and still giving credit to the authors. The idea of an international band is realistic, with members each from a different country in the world. 

Of course, there are drawbacks to this idea. It's very complicated, and would require some knowledge of sound file manipulation. Servers would be required to hold user generated content, which in turn would cost money. And of course, the main problem would be getting it off of the ground. Because all of the content is user generated, before there are many users there would not be very much content to attract new users. This is always a big problem with sites that are community driven. However, despite these obstacles, this idea has huge potential to change the world, or at least the world of the music industry. It has the potential to realize the vision of something like Soundcloud, but allowing the freedom of collaboration. 

Thoughts on Wikipedia

I'm here writing about the Wikipedia article on software engineering, linked here.

Software engineering is basically the practice of programming in a business environment, but it is much more complicated than that. Because programming is learned in a very solitary manner, it is easy to think of  it as a introverted profession. However, this becomes immediately complicated by the fact that the programmer has to make a product for someone who usually does not know how to program. This makes it the job of the programmer to "translate" between the user's wants and the machine's capabilities. This can be extremely complicated since many people really have no idea the amount of work even a simple (in their minds, at least) task can create.

Dijkstra's quote on the wiki article is highly relevant:

"if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."

But why would Dijkstra have such a problem with software engineering, when there are clear problems with communications between programmers and end users? Well, many criticize the amount of work that goes into setting the up the program prior to even beginning to write code. So much work goes into this idea of communication, some may question whether it is a worthwhile pursuit at all.

Another interesting part of the wiki article is how it talks about the difference between software engineers and other types of engineers. This is taken from the article:

"One major difference between software engineering and other engineering disciplines is that software engineers are not yet able to precisely describe and measure (a) the materials they use and (b) the results of their work, i.e. what a piece of software does. Other disciplines use Meter,Volt or other units of measurement. In contrast, the measurements available for software like e.g. Lines of Code, Function points or Complexity Measures only capture the amount of software created. They do not describe what the software actually does. This is like describing and measuring a complicated piece of machinery in kilograms only. So describing and measuring software is a challenge which remains open to this day"

How does one go about measuring a piece of software? Is length an important metric? Is performance? Function? And how would you even measure the latter two? Personally, I would say length is irrelevant. Sure, sometimes you want to show how much work you've put into something and you can say, I wrote 10,000 lines of code. However, something that might take you 100 lines of code could take someone else 5 lines of code. Is there program any better or worse than yours? You can't say from the information given. Perhaps theirs is extremely unreadable because it is so condensed. Or maybe yours has way too much fluff. Either way, if it produces the same program, does it really matter? Performance and function are more important to determining metrics of a function, but there is no realistic ways to measure them in an objective way.

Despite its relatively simple idea, software engineering runs into some major questions when trying to be defined. Personally, I will have to read a lot more about it before I would even attempt to answer some of these questions.

Ronald