Imaging the following situation: your team is having a meeting in which you have to decide which features, components to build for next product or service release. Or by having a specification from system analyst you have to decide how long it would take to build the desired product so appropriate offer can be made to the client.
Either way it is very important what you will decide because all future changes will be around this very first decision. You are setting the expectations and this is very important for the project outcome.
One very popular technique is asking the developers for their estimation. Once the team leader has this number it multiplies x2 and gives it to PM. PM also multiplies it x2.5 so there will be good buffer zones. This approach, funny or not, somewhere works. And there are happy customers and ISV.
Yesterday I attended Seattle code camp and a very interesting session was “Agile Estimation Techniques” presented by David Starr.
 (image by old.crisp.se)
| The idea is simple: everyone from the team has a deck of cards. Having once already solved problem/built feature by the team is set as base one at well-known cost (in man-days, man-hours, ). Then another upcoming tasks is put on the table and after initial discussion everyone of the team lay the card of choice representing their thinking of the cost.
If there are big difference if some team members’ choice let them discuss their choice and repeat until everyone pick closer costs. |
Look interesting, doesn’t it?! Read more here:
 | "What you're holding in your hands in by far the most brilliant book about managing software teams you're ever going to find. If you’re in a bookstore, buy it immediately, take it home, and read it right now. If you’ve found this book on a friend bookshelf, steal it immediately. You don’t have time to get to a bookstore, and you can always make new friends later."
Joel Spolsky, cofounder and CEO of Fog Creek Software
|
Fortunately I didn’t have to spoil any friendship and I was able to borrow the book from corporate library. With a series of tales Michael Lopp introduces the reader into the world of the tech manager. Whether manager or just wannabe this book describes very interesting situations and cases which can benefit you in so many ways. If you haven’t been in such situation yet you can mentally prepare for it and have an idea of good action in the back of your head when one occurs.
Ability to be in someone’s shoes is so rare and combined with good writing skills creates a wonderful must-have book.
This book is really so interesting so I am going to read it in just two days…
It is very good practice to have several environments when creating a software solution - typical environments are Development -> Integration -> Staging -> Production environments. Also having Automated Continuous Integration server like CruiseControl.NET can greatly improve teamwork and quality of developed solution. Of course having a solution build (by CruiseControl.NET) you might want to have the installation project also build... and you will need a deployment procedure so the steps would look like these:
- Check-in source code changes
- Trigger a build on CI build server for the solution
- Trigger a build on CI build server for the build package
- Execute publish script which will deploy binaries to certain environment/servers and will change app settings, connection strings etc.
Example project setup can be seen on Omar Al Zabir's blog post ASP.NET website Continuous Integration+Deployment using CruiseControl.NET, Subversion, MSBuild and Robocopy.
Of course having all changes for different environments in publish script would make it big and difficult to maintain. This is why it is better to keep all environment/servers specific settings outside of the project. One option is machine.config. And storing it in source control, of course.
Another option is having all those settings in separate folder. I wasn’t aware of this option of .NET Configuration API and I was disappointed when I found that XInclude is not supported. Fortunately there configSource section attribute which allows to achieve same functionality. For some ( more here ) this might be well known but I found this recently and AFAIK it is not widely used.
So you can specify web.config/app.config file like this:
1: <?xml version="1.0" encoding="utf-8" ?>
2: <configuration>
3: <connectionStrings configSource="ConnectionStrings.config" ></connectionStrings>
4: <appSettings configSource="settings.config"></appSettings>
5: </configuration>
and then specify actual configuration in external files. Here are my examples for ConnectionStrings.config
1: <?xml version="1.0" encoding="utf-8" ?>
2: <connectionStrings>
3: <add name="cs1" connectionString="Data Source=myServerAddress;Failover Partner=myMirrorServer;Initial Catalog=myDataBase;Integrated Security=True;"/>
4: </connectionStrings>
and Settings.config
1: <?xml version="1.0" encoding="utf-8" ?>
2: <appSettings>
3: <add key="s1" value="Some very important setting"/>
4: </appSettings>
As you can see from example the only important thing is to have root element of external file named same as referenced section in the core config file.
and after that you can simply get the values as usual:
1: class Program
2: { 3: static void Main(string[] args)
4: { 5: Console.WriteLine("cs1: {0}", ConfigurationManager.ConnectionStrings["cs1"].ConnectionString); 6: Console.WriteLine("s1: {0}", ConfigurationManager.AppSettings["s1"]); 7: Console.ReadLine();
8: }
9: }
This means you can refactor configuration of existing .NET applications without having to touch the code or even recompile. Just be careful :)
Happy XML/Config refactoring :) !
Thanks to Derek.
So this is the world of software development. Welcome in my world :P
"...my main conclusion after spending ten years of my life on the TeX project is that software is hard. It's harder than anything else I've ever had to do."
Donald Knuth (read more)
It is not big, hot news right?! :) I knew it is not just me:)
But here is one: If you think that software is very different than other engineering areas you're wrong! You think that software is very different because it is hard to estimate?! well... keep reading.
The most massive cost overrun in history: Boston Big Dig highway was initially estimated at $5.8 billion.
"Eventual cost overruns were so high that the chairman of the Massachusetts Turnpike Authority, James Kerasiotes, was fired in 2000. His replacement had to commit to an $8.55 billion cap on federal contributions. Total expenses eventually passed $15 billion. Interest brought this cost to $21.93 billion."
Source: Wikipedia
Software business is quite different than other businesses. Mainly this is because in software there are very few routines that can be set as standardized actions, write action plans for them or so on. Let's take retail business - although it has it's own specifics in major part the manager can define in what threshold of goods availability make order to suppliers, or when to put some goods on sale and so on..
In software is different. While in others micromanagement (although bad in general) can be applied in software is impossible.
This is why we have so many methodologies: Waterfall model, Spiral model, Extreme programming and so on...
But where is the secret to success? There is no single answer to this question. But Joel Spolsky shared his experience working with BillG - more especially having him making a design review...
Bill Gates was amazingly technical, and he knew more about the details of his company's software than most of the people who worked on those details day in and day out. He understood Variants and COM objects and IDispatch and why Automation is different than vtables -- and why this might lead to dual interfaces. He worried about date and time functions. He didn't meddle in software if he trusted the people who were working on it, but you couldn't bullshit him for a minute because he was a programmer. A real, actual programmer.
and more
Bill doesn't really want to review your spec, he just wants to make sure you've got it under control. His standard M.O. is to ask harder and harder questions until you admit that you don't know, and then he can yell at you for being unprepared. Nobody was really sure what happens if you answer the hardest question he can come up with because it's never happened before.
Read the whole story (here too) and you will learn some interesting things as how Microsoft made such great product as Excel, how deeply the management should be involved in the details; What is F-counter and how it is related to design reviews :).
All of us has heard of software companies that achieved a great success - Microsoft, Apple, Yahoo.. more recently Google and Skype. As we are technical people we tend to think it is related entirely with some super-duppa algorithm, smart software or you name it... built even in a garage. In most cases this is the initial power that make them move. But after initial start there are another factors that counts.
Have you wondered how is possible to build world class product with team of 5 and within a year to have a team of 100 (or 1000) doing same thing? This is very dangerous situation because there is a moment in a young company when nobody knows what exactly are their responsibilities. It is dangerous because clients starts to suffer low quality of service. Having many teams require a lot of communication and not knowing how to structure it a lot of precious time is wasted. Such situations requires a good leadership.
The companies that has success had a leaders to help them. And leadership has small to do with technical problems. Dale Carnegie points this very accurate:
Even in such technical lines as engineering, about 15% of one's financial success is due one's technical knowledge and about 85% is due to skill in human engineering, to personality and the ability to lead people.
Dale Carnegie
Software industry is very different to other well known industries and in same same time very similar. Leadership is very same.
Employees are not told what to do anymore. Now, you influence their choices and assist them in reaching their goals. You do not direct; you win the team over to your point of view. You do not dictate; you inspire! You can learn how to convey this inspiration by focusing on your leadership skills development. Leadership development is needed to successfully take charge of your team in today's business world.
dalecarnegie.com
Microsoft released a nice training kit for the latest technologies that will help you to become a real hero very quickly.
This package is a real treasure because it covers a bunch of technologies:
- C# 3.0
- VB 9.0
- LINQ
- WPF
- WCF
- WF
- Silverlight
- ASP.NET
- AJAX
- CardSpace
- Mobile
- Visual Studio Tools for Office
- Visual Studio Team System
- Application Lifecycle Management
|  |
And the materials are of the different types:
- Presentation - will be very helpful to prepare talks for community
- Demos
- Labs - very helpful to walk through new technologies in deep.
Go grab it!
I've just read an interesting article on Wired.com: The Micro-Multinational.
And the story begins with a programmer in US who outsourced his own job to a guy in India. The magazine says this is "all win" situation because:
By subcontracting out the generic parts of his job, the programmer gives himself a promotion. The Indian developer is well paid. The employer gets good code.
I would strongly disagree: at least the employer gets code with a delay because of additional communication between a US programmer and the one in India.
I am also strongly for outsourcing as long as it put a brilliant people together to create a better product. But the quality should not suffer. Also it is not very loyal to keep this as a secret to the management because delays should be considered in the estimations (which are hard enough to create :) in software business ).
That's the true! No matter how you motivate and stimulate them, they will never will perform like the founders in long run. And this cannot and shouldn't be expected from them. They care about what's their job like today! They won't sacrifice for long run.
Founders are another story. They work tireless days, nights, during weekends putting on risk family relationships, friendships and even their health. But the bet is a way different. Success could bring them a fortune.
On the other hand success will bring a bigger salary, bonus, maybe shares to employees. No matter how big these are they cannot compete with the benefits of the founders. That's why there will always be difference between founders and employees.
In software business is normal to have 2-3 guys who makes a small company and create first version of the product. This version is created in no time - everyone in the team knows all the details and work on them no matter of the clock. And when this version is a blockbuster and it is time to hire some hands to help on next one the expectations are so high. Performance will never be the same.
Note: I am not saying that it is bad being an employee or a founder. Each situation has its own pros and cons :).
(These thoughts are inspired by Joel Spolsky's article "How Hard Could It Be?: Lessons I Learned in the Army")