Alexander Rauser

Latest Updates: Project Management RSS

• 

  The Automation Myth

  admin 8:52 pm on October 4, 2008 | 0 Permalink
  Tags: code automation, Project Management

  Recently one of our developers showed me a tool with which he could create a CRUD application by only creating the database model, run a script and in return get pages full of data grids to update the data in the database. I forgot the name of the tool, but you probably know one of these code automation tools anyway.

  The common USP of framework vendors these days seems to be automation, which doesn’t really make it an USP anymore.

  You can create code in less time, no – you can create code in less time without coding! Sounds promising, but reality looks different.

  Let’s take Django, the all new fancy schmancy web framework. You create your model in Python code, run the command line tool and get this beautiful looking admin interface. You saved two weeks worth of work and you feel pretty rich at that time, since you think you can sell this to your clients – without even coding!!! Then after two weeks you wake up as you figured out you spent the last 10 days learning how that admin interface actually works. Unfortunately your client needed a rich text editor and image upload in a relational data grid and all your efforts to convince Mr. Client that this is nonsense failed.

  Code automation only works if you understand the underlying technology. Anything else would be like flying an Airbus with a single engine Cessna license.

  This doesn’t mean that admin interface is useless, but we probably agree that it will be pretty useless, if you are unable to customize it. In order to do so, you have to understand how it’s written.

  Code automation only helps us if we understand the code that was created, the result is customizable and the learning curve is smaller then the effort it would take to just “do it yourself”.

  But there are good reasons for using a piece of code even if you don’t understand how it works underneath the cover or if you can’t see what’s under the hood. I am talking about libraries or components that you can plug into your application and use for a very specific purpose. There is nothing wrong with buying a piece of functionality. The cost of reinventing the wheel is much higher then just buying that PDF library for $99 or do you really want to read through the PDF ISO Specs and rewrite it from scratch? (If you now switched to your text editor and started hacking to proof something you might want to check this first)

  Buying functionality makes perfectly sense if:

  1. You get as much as customization as you need to
  2. You can brand it your way, so it looks neat and integrated
  3. The time to learn the API is smaller then the time required to build your own (Yes, there is still bad documentation out there)
  4. There is some sort of support or knowledge available to speed you up
  5. It is compatible with your development environment
  6. It is not likeley to disappear from the market in the near future

  One mistake I encountered a lot was to chose the component without proper evaluation. Even worse, without checking the functionality against the spec. As mentioned before using code automation requires to understand the code that was thrown at you after you pushed that button. Components, even though you don’t need to know how they are written or what they do in the background, still require you to learn how to use them. I watched people spending as much time learning how to use and customize a bought-in component as it would have take them writing the whole thing from scratch.

  Automation is not a bad thing after all. Many software companies spent quite some time to develop tools that make their delevopment process more efficient. Automated build scripts, IDE plugins, or even reusable components can be a big time saver.

  For our content management system we have written several modules, such as news, blogs, image library, application forms, video streaming integration etc. and every time we need one of them we spent 80% skinning the front-end user interface and save time for every component we can reuse on the back-end. The team knows each component inside out and every programmer is able to modify or customize the control. Better, even the designers know the capabilities of the controls and design the application according to the specification in the first place.

  In any case, automation is good if you understand what it produced and the configuration of the automation takes less time then writing the code yourself. Buying components or libraries is great, if they do what you want, are easy to use and integrate into your application.

   
• 

  A night of multitasking

  admin 4:36 pm on October 1, 2008 | 0 Permalink
  Tags: bug tracking, Project Management

  Last night we had to work towards a deadline. Thankfully this doesn’t happen too often, but we ended up sitting with 4 people in the office working away. Most of the work had to go through one of our user interface developers. The later it became I saw the poor guy running around between a programmer, an account manager and myself – plastering him with amendments :/

  Every time he sat down back on his desk someone else called him to note something. It went on forever.

  It was a typical example; you forget about all the great tools you use during the day in the heat of the night.

  “Let’s skip the bug tracker so we are faster” = wrong

  Reporting the bug usually takes less time then fixing it. So sitting next to each other waiting for one to complete and then brief the next change takes two peoples full time.

  In addition for every task we usually need to understand, prepare and perform something. Theoretically this would mean, that if we have to do all these steps anyway, it doesn’t really matter in what order. The result would be the same.

  In reality jumping between tasks that are not related to each other consumes more time. We need to understand the bigger picture for each task, prepare a completely different environment, open different resources etc.

  

  Figure 1: Time to understand and prepare a task take less time when working on consecutive tasks

  At some point we started putting all amendments back into our bug tracking system as we are used to. This enabled him to to pick amendment after amendment and saved his sanity and some time.

   
• 

  Rock Star Setup

  admin 8:42 pm on September 29, 2008 | 0 Permalink
  Tags: Brooks's Law, Project Management

  I sometimes watch developers with 20 windows open at the same time trying to find their web browser, which takes them around 15 seconds and then they have 34 tabs open in FireFox and they click back and forth randomly to at some point find the page they are looking for. Then they forgot what they actually planned to do, so they switch back to wherever they came from to copy some chunk of text and they navigate back to that window… – quicker this time as the tab in the browser has already focus.

  It’s the multitasking problem. The more you multitask, the more it will slow you down. But not only the number of different tasks for different projects can decrease productivity, also the number of team members.

  “Adding manpower to a late software project makes it later.” Also known as the Brooks’s Law.

  The concept is that for each team member you add to a project the intercommunication effort increases by n(n-1)/2 as shown below.

  Figure 1

  So let’s say we have 6 members in our team, this would mean that all of them have to communicate with each other in order to complete the project; assuming they have to know what each other is doing.

  This would create 15 communication channels or communication paths as shown in Figure 1.

  If we then assume 20% of the actual time required to complete the project as the communication effort per communication channel we will figure out that the more man power we add to the project the more time we require. As shown in the table below, theoretically 10 people take as long as one team member by himself.

  Members	Time Required in Days	n(n-1)/2	Communication Effort	Actual Time
  1	20.00	0	20%	20.00
  2	10.00	1	20%	12.00
  3	6.67	3	20%	10.67
  4	5.00	6	20%	11.00
  5	4.00	10	20%	12.00
  6	3.33	15	20%	13.33
  7	2.86	21	20%	14.86
  8	2.50	28	20%	16.50
  9	2.22	36	20%	18.22
  10	2.00	45	20%	20.00

  In our example we are most productive when we are working in a team with three members. This observation does not only apply for software development, but for any creative team effort. (I even experienced this with our school band – we never wrote a song until we limited participants to 3 members only

  Examples are projects that are completed by a single person. Projects that would usually require a big team of developers. The guy who started http://pixlr.com/ has built most of the application by himself within just a year of his spare time.

  Our most successful tools and products are those that where developed by a single person either as a requirement or a proactive solution. It’s like a prototype that becomes a real product. Usually we noticed that progress slowed down drastically once a team took over the development. Taking the conclusion that it would make sense to have just one person working on a project for its life cycle is not a good idea though. At some point we need to think about support, maintenance and other tasks that require a team setup.

  I call it the Rock Star setup – let him do the show and let the band take care of the music. Never forget they can’t play a show without each other.

   
• 

  Interactive Project Evaluation

  admin 2:38 pm on August 29, 2008 | 0 Permalink | Reply
  Tags: Project Management

  Our project work flow usually starts with a specification and a design. So, by the time we start the actual work we have done a lot of preparation work. There are briefs, meetings, quotations, presentations, proposals, designs and specifications.
  
  Now, each project has a certain budget and the budget represents the time we have to complete the project. Each project also has a team of people working on it. We usually have a minimum of one designer, one user interface developer, one programmer and one interactive developer in a project team led by the producer.
  
  If a project was successful or not can not be evaluated by only comparing the cost to the budget. There are many factors we can use to improve our processes and products.
  
  Taking a snapshot of the project can help to give better figures. A snapshot can be determined by taking the start of the project and the time the requirements of the initial specification have been completed.
  It’s important to track if the spec has changed, because a change in the spec can result in more or less time to be spent.
  
  The team working on the project needs to be evaluated as well. A meeting after the project was completed should include all team members in order to discuss what went well and what needs to be improved. Also, the team setup might have been wrong, if you only have the rock-stars in one team and the juniors in the other teams you get most likely uneven results. You don’t want to stop a winning team, but you also want to have many winning teams and not just one.
  
  Deadlines are an important influence as well. You might work towards a deadline which makes your team stay longer or work faster. This is great as you complete the project in the allocated time. At the same time one of the rules in interactive development is, if you do a quick and dirty job, it will come back to you quick and dirty – sooner or later. Finding the right balance is all based on experience and one of the complexities we have to deal with.
  
  Quality comes next. We said quick and dirty before. You might hit the deadline, but it’s just not as nice as you wanted it to be. Evaluating the quality of the work helps to improve and aim for better results. The complexity of the project matters as you will deliver that email shot in time without problems, but that real-time-market-watch-application will just go on forever. Therefore a more complex project needs to get more attention and needs to be looked at in a different way.
  
  Task size is important as well. The smaller the tasks that you define the easier for all team members to understand the project and their responsibility. Defining tasks also leads, whoever puts the tasks into place, to actually think properly and in depth about the project.
  
  

  Points to evaluate

  • The Team, member and role
  • Spec and spec changes
  • Problems occurred and suggestions to avoid them
  • Was there a deadline or a timeline
    
  • Quality of the result
    
  • Complexity and difficulty of the project
    
  • Task size and allocated time

  
  

   

  Reply Click here to cancel reply.

  Name (required)

  Email (required)

  Web Site