....was granted without adequate review of prior art, and further, that even were it ultimately found valid, such broad patents serve only to hold back further innovation.
It is plainly wrong for companies to take our IP protection on overly broad terms, which are already in the public domain - but to then seek to enforce them is clearly even worse.
The writer of the Open Letter to Jeff Bezos knew what he was talking about.
In this article, Lawrence Lessig explains why broadband sucks in the US - but he draws almost the opposite conclusion to the author of this piece...."Let the markets, both private and public, compete to provide the service that telecom and cable has not."
I think you may be underestimating the skill and experience a good front-end designer brings to bear on a project. Imagine somone asking "I know how to code pretty HTML and I'm a photoshop wizard, but now I want to do a 2-week course and learn servlets and database programming so I can offer the whole package". You can absolutely look at improving your skills as a designer - someone mentioned Nielsen, you might also want to read Alan Cooper's "The inmates are running the asylum", and Joel Spolsky's book on user interface design, and maybe grab a book on general graphic design basics (colours, typography, layout) - if you have a good eye and are meticulous, that should improve the general look of your work. Just don't expect to go on a 2 week course and become a UI whizz.
I joined a startup as CTO in the hay day of the bubble. We had some money - not enough - and very little time, so we hired 2 companies to build our product. Now, I can code. I understood the problem domain, I have a lot of experience managing complex projects and 3rd party suppliers, and we knew pretty much what we wanted. It was still a nightmare. Here's what I recommend:
Find a business partner, ideally someone who complements your skills (a techie might be a good idea...). However good your idea is, I bet it will benefit from a second pair of eyes, an enthusiastic supporter who will offer constructive criticism, highlight angles you hadn't explored, and keep the project moving along while you're out rustling up more money.
Get the team together in the same space. There's really no substitute - if it means spending some of your precious capital to hire a motel room somewhere close to whoever does the work for you, it's probably the best money you will ever spend. Here's the skinny - when you're building an experimental product, there's no substitute for instant feedback. The people building the code will have a hundred questions, ideas, dilemmas every day, no matter how good your specifications, and cutting down the amount of time they have to wait to get an answer from hours to seconds really - really - pays off.
Insist on daily progress reports, with daily delivery of intermediate artifacts. Make sure that you keep a very tight handle on the day-to-day progress of the project, and make sure you understand the direction the product is taking. That means getting access to everything that is produced - not just pretty gantt charts and powerpoints, but the working designs, the code, the proof-of-concept doodles. Be absolutely relentless in establishing your vision, but make sure you are open to other ideas - fold them into your vision if they add immediate value.
Incorporate as early as makes sense - though I admit I have no idea what the situation is in Japan, in most countries it is usually worthwhile incorporating as soon as you are ready to start full-time work on your project. Find an accountant to fill you in on the details.
Now, a brief word about equity - you have to balance the value of your cash against your equity. If you retain 100% of the company but go bust in 6 months for lack of cash, your equity is effectively valueless. On the other hand, if you hand 95% of your equity to a blood-sucking VC and your company goes public at a value of $100 million, you will _feel_ like you lost 95 million dollars, and you will almost certainly lose control of the company. Now, it is absolutely true that giving away too much equity too early is almost certainly going to mean you lose control of your company. But if you can find a bunch of decent programmers who are willing to work for a bit of cash and a reasonable equity stake, you have a decent chance of holding on to your cash for a while longer, getting some highly motivated business partners without losing the farm. In case you're interested, we rewrote 80% of the original code within 6 months, the company's still alive but never really got the impetus we all hoped for, and I left after around 18 months.
And the TDD book by Kent Beck shows how the evolution of an application can be driven by unit tests. Fwiw - I'd suggest that a large project is _not_ the best way to get to understand how unit testing works - there is likely to be way more detail than you need or want. Matt Raible shares some code (esp. AppFuse) which includes unit tests, and describes them in his wiki on Appfuse tutorials. His "Struts Resume" demo application contains some pretty interesting unit tests of a real-world application. Now, here's the skinny for me : using testing as an integral part of your development cycle helps you to separate the layers and components in your application. Every time you find yourself thinking "how am I going to test this - it's too difficult/intertwingled/dependent on other stuff", you have identified a design deficiency. Making the software easy to test will make it easy to understand, and easy to work with in future. By architecting the application to make it easy to test independently of the database, you make it resilient against changes in the underlying database technology, and - oh, yeah, you have some self-documenting code to show others how to call your api. Good place to start reading is Robert Martin's "Agile Software Development".
I've been managing software development teams for around 7 years now. My initial promotion into management was scary - I was working on a politically highly sensitive project, using technology I'd never seen before, when the project manager left. He was one of the most respected managers in the organisation, and I was asked to take over the project - which was still at the very early stages. I thought about many of the same questions posed in this post - I knew how bad the politics were likely to get, I didn't feel comfortable with the technology we were using, and I didn't think I'd get the corporate support to help me deliver. But I took the challenge. Why ? Because I saw that delivering this seemingly impossible project would strengthen my position as a manager, because I believed in the team we'd created, and because I did my homework. Homework is essential : I made sure I had a mentor. He was a senior manager elsewhere in the organisation who could help me work through managerial issues, and pull a few strings when I needed to bypass a political hurdle. I sat down with the team members and worked through our plan for the next 10 weeks and saw we could achieve our goals. The team members and I discussed what the change from "co-worker" to "boss" would mean for us all, and we were all fine with it. I discussed the project in detail with the person who would become my new boss, and made sure he had the wherewithall to back me up with a lot of the politics of the situation. I drank a lot of coffee with the other manager at that level to find out the realities of the situation, and then I made the jump. It worked out for me - but I made sure I understood the situation well enough to believe the odds were in my favour. It took hard work, a lot of help from the team and my peer group, mentor and boss, but our project was an outstanding succes. I was rewarded with - guess what - new projects which were in way more trouble than that first one. So, think about what it means to be a manager. As a manager, your value to the company is largely your ability to get other people to perform at the peak of their ability to fulfill goals that further the company's interests. That means your value is far greater if you rescue a failing project than if you take over a project that is already near-optimal and maybe eek out a couple of improvements. You personally will learn far more from managing a project in trouble (as long as you have the organisational support that makes a succes possible) than from taking over a surefire winner. Take the opportunity to learn - but only if that is what you want, and if that is what you think you are good at.
Security is a process, not a product (no, I didn't make that up - check Bruce Schneier's company). Security is a fairly wideranging topic, and involves at least half a dozen different, highly specialized disciplines. You may not need to be particularly thorough in all of them, but if you follow the great advice to use Nessus for network scanning, you may not realize that your client has left a gaping big hole in their ASP code which will allow arbitrary database requests to be executed against your client's database. Or, you could have tightened down your network and website, but have no protection against viruses or worms on the desktop. Or there may be a wifi point allowing access to all and sundry. Or the server room may be accessible from the kitchen where many casual staff work. Or your client's CEO's daughter's boyfriend might have access to his PC with a VPN connection that automatically starts without prompting for a password.... So, yes, it's a good idea to use automated tools to do a basic audit. Nessus is good. You could do worse than read "Hacking Exposed" - it mentions a lot of good tools, both free and commercial, as well as the basic process for conducting a security audit. However, make sure your client realizes that a clean bill of health (or fixing the issues your tools reported) does not mean they are "safe", (nor that they can sue you for any breaches that might occur), but rather that their organisation is not vulnerable to the attacks you tested for. If you didn't "test" hiring practices, they have no idea whether they are protected against employee fraud (which is still by far the most common form of computer crime). If you didn't "test" their virus protection policy, they have no idea of how exposed they are to the next email worm. And of course, you are never "safe" - new threats emerge every day, and a server that was as safe as Fort Knox yesterday might be more like a crackhouse when the latest spl0it is released. So it's an ongoing process - assess, evaluate, repair, repeat & rinse. Now, if your client is a small local firm with family members as employees, who use computers only for non-critical tasks, the "we'll run Nessus once a month" approach might be okay. If they are - oh, say, Microsoft...- that approach is clearly not sufficient.
Think about the interests of your client - not just in terms of saving them money, but protecting them from risk.
in fact, you should avoid any promotion opportunity which might require wit, determination, creativity and the ability to fix stuff or motivate people. In your place, I'd hold out until they offer to mail you your pay check at home while you telecommute. It's a well-known fact that all managers are lazy and stupid, so why expect to get promoted for doing something even remotely resembling work ? Oh, and another really helpful tip - use Startrek as the basis for making life decisions. No, really - it's sooooo realistic !
It all depends on what the course being taught is. If you are teaching computer science, I concur with the "read the writings of C.J.Date before touching a computer" post. If the course is "office automation tools" or somesuch(what is the school of communication, anyway ?), Access is certainly suitable - it's very accesible for non-techies. For what it's worth, I think it's a mistake for a University to teach people who are likely to end up in a programming career using Access - any prospective employer will look at a CV containing Access and think "macro monkey", not "code guru". Check the job-sites - programming jobs usually require a server-scale RDBMS; secretarial and office support jobs require Access. When I hire for programming jobs, I usually assume knowledge of any of DB2, Sybase, Informix, Oracle, Postgres, MySQL, MS SQL Server will relatively easily transfer to our platform, but that someone who uses Access will be too bound to the query builder interface to get up to speed quickly.
on the BBC (radio 4, Midweek, 5 Nov 2003, I think) in which he told the interviewer he had an absolutely crucial scene in the final episode - he seemed to believe it was going to be in the film, I'm sure !
And abstraction is the fundamental means of reducing complexity. The history of programming is the movement from physically inserting patch cables to program a computer to manipulating abstractions. In languages like C, those abstractions are still pretty close to the hardware; in OO languages they tend to be closer to the problem domain. Edsger Dijkstra once said that software development was unique as a profession because it required practitioners to operate at 7 levels of abstraction - from transistor to algorithm to software architecture to business domain. Of course, very few of us deal with "transistor-level" programming these days. So, Simonyi's "intentional" programming is part of this broad sweep of improvement in programming languages in the last 50 or so years. The current emphasis behind Model-driven architecture is a similar desire to somehow take away all that messy code stuff and replace it with nice, easy to understand pictures.
The problem with both these approaches is that complexity exists inherently in the problem domain. The role of a software development team is to chose a path through that complex problem domain and implement it with working code. Right now, I don't believe we have tools which are sufficiently expressive and intuitive to model the complexity of the problem domain, and we must be years if not decades away from being able to convert such models to working code. UML is lovely - it's a great language for expressing software ideas and conveying a lot of information in a graphical format, but the average business user just does not get it; in my experience they are primarily useful for communicating between developers. Use cases (in textual form) are far more useful for communicating with business users, but to convert a usecase into a working program would require natural language parsing at a level that must be a generation away.
We should wish Simonyi luck - his ambitions are worthy, and will benefit all working developers if they bear fruit. And what better use to put a couple of billion dollars to ?
I used to be the development manager for a content-based website, and we had significant performance issues. We had a limited budget, and buying even tens of thousands of dollars worth of licenses was - in our view - a bad use of that budget. Instead, we concentrated on building a test infrastructure with known performance characteristics, and extrapolated (sorry, I meant "guessed") that this performance profile would scale by a factor of X on the live infrastructure. By using a relatively small and flexible test infrastructure, we could rapidly cycle through load test scenarios and find whether any particular change moved us in the right direction. We determined a set of key performance criteria for the test infrastructure, and found out quickly what the overall trend was because we could run several fullscale loadtest scenarios per day. We used Loadrunner - but only using a limited number of concurrent users (100, I seem to recall), and since then I have used apache.org's JMeter product with similar levels of success. As far as I know, if you absolutely have to be able to simulate thousands of concurrent users, the Mercury/Rational style commercial tools are the only ones available. I guess there are circumstances where this is appropriate - but the sheer effort of organising and running a test on that scale is a huge pain in the backside. If you can find a way to scale down your testing requirements - by running on lower spec infrastructure with optional throttling on key components - you reduce your licensing costs and improve the flexibility of your test process - if you can run several load tests a day without dimming the lights throughout the neighbourhood, load testing becomes "just another test", rather than a big deal.
The same question was asked in an XP usenet post. In fact, in Kent Beck's book on eXtreme Programming, he discusses the cost of changing software in the various stages of the development process, and a recognition that this "10-100-1000" progression is not necessarily true is a fundamental part of the XP philosophy. For what it's worth, I believe there are many domains where that cost escalator does not apply. If you have a well-designed application rolled out to a manageable userbase with access to a helpdesk or the development team, it is fairly cheap to release software, and it is cheap to find and fix bugs. It's reasonably cheap to find and fix bugs on web projects, too. There are also domains where fixing bugs after the release is extremely expensive - embedded devices, shrinkwrapped software, software subject to regulatory checks. At the time the metrics were collected, compile times were a significant issue for pretty much all developers - the "code-compile-test" cycle could be hours or days. Nowadays, most of us can compile our application in seconds or minutes (no, not the linux kernel. Yet.) IDE's and case tools have made it easier to understand code, and we have debuggers which allow us to look deep inside the application in real-time. I don't think the "one-size-fits-all" metric was ever valid, just as there is no "one-size-fits-all" development process. I think the ratio for any given project has gone down from its level in the early 1980s, though.
I've used it and basically had a quiet rebellion on my hands in the software development team. I strongly recommend that you look at how you are currently using MS Project - I love using it to plan projects, but I hate using it to track projects. If you are tracking the project using Excel (which you appear to be hinting at), you may find that a plan which is detailed enough to get your project off the ground is totally unsuitable for people to submit time-cards against (was I working on the fooble component or the integration of the greeble ? I spent half a day longer on the fooble than the project plan says, but my greebling went a lot faster - aargh ! I can't book more than the allocated hours ! Aaargh - I'll ask my manager to extend the number of hours for my foobling - manager loses will to live). I quite like xplanner - it's designed to work with eXtreme Programming rather than "traditional" project management methodologies. For "enterprise" class, I'd suggest the Rational toolsuite....
The software solution you need depends on the process you want to implement. For instance, do you just want any bozo to be able to assign work to you "because Bob said you were the person who does this kinda thing" ? Or do you want your PHB to have power of life and death over your to-do list ? Do you really want to tell the chief executive to use some web-based system to get his requests acknowledged ? Do you really want to mix major projects in with requests for a new network cable ?
The reason you are finding it difficult to find the software you are looking for is because none of the packages can address all your concerns. So, do what you would (presumably) do for any software project - get a couple of stakeholders together (from the business as well as IT), work out what you want, and then see how to address the need. If you start off with "from now on, we will use SuperRequestTracker Pro and all you plebs must learn it's intuitive interface to get your stuff done", you're pretty much doomed.
Check out Arthur Middletonof Covent Garden, London, a purveyor of antique globes and scientific instruments. This is the shop you always wished you could visit as a kid - it's full of telescopes, microscopes, globes, sextants, apothecary bottles - the only thing missing is a stuffed crocodile hanging from the ceiling. They provided some of the props for Prof. Dumbledore's study in the latest Harry Potter film, and I personally believe that you can't get geekier than
A 19th century Zograscope, on an attractively turned mahogany column. We are tempted to say that the device was invented by King Zog of Albania in 1928, but it wasn't: it was first produced in 18th century France as an optical aid for viewing prints of landscapes. Overall height 60cm, nearly 24".
I mean, who wouldn't want a zograscope ? And only GBP950.00 !
and from my point of view, I don't particularly want to hear about the hours you worked. I effectively want to treat you like any other supplier - I want to be able to weigh costs versus benefits. I want to know that I can pay you $2K to build me a furtzwangler, and get $3K's worth of value out of it. I don't want to hear about how your PC needed to be reformatted (in my time), or how you looked at a cool new solution to a particular design problem (in my time) or how you had to rearchitect your OO persistence layer using the gesundheit design pattern. It comes down to risk : software development is inherently unpredictable. Someone is going to have to take a risk - will the features I asked for take 6 weeks, 6 months, or 6 years ? You are in a far better position to estimate the duration of the project than I am, so it's only fair that you bear the risk. Of course, that assumes that I am not a psychopath who changes the requirements every week and "forgets" to tell you it also has to run on the Amiga platform. That is the risk you bear - you might be able to build the required features in 6 months, but not if I keep changing my mind.... So here's what _can_ work as long as there is an amount of trust between you and the company who want to pay you.
Agree in advance a feature list; each feature needs at least a paragraph or two of descriptive text so both parties understand the question.
Independently, you provide a rough estimate of the amount of work, and your client ranks the features in terms of priority.
You both select features which can be implemented in a relatively short time-box (2 to 4 weeks is ideal). You discuss those features in detail so you are clear on what you've got to do, then agree a price for that work (multiply your desired hourly rate by the estimated amount of work, duh). You agree not to charge more than the agreed price; your client agrees not to change the scope of your current iteration by asking you to implement something you haven't already discussed. If they want something extra, they can wait till the next iteration.
Build what you agreed to build; keep in close contact with the client, and show them at least once a week what you've achieved.
At the end of the iteration, deliver the agreed features to the client or into the open source code base; rince & repeat.
This allows you to reduce your risk by not allowing the client to change their mind once you've agreed your current iteration's scope. As the scope of an iteration is likely to be relatively small, your client does not have to make a big, irrevocable decision about what they want exactly so you can do a big complicated estimate. The risk is effectively shared. By seeing how much you get done in your iterations, you get a way to adjust your prices in a way that reflects reality - if it turns out you had to work day and night to complete your iteration, you need to charge more (or reduce the scope of what you take on in an iteration). If you have time to spare, you can take on more in the next iteration.
is worth reading - he writes very eloquently on this topic. From personal experience :
Hire a hard-ass financial controller. Make sure someone asks all the hard questions about how growth gets funded - don't rely on the customer-facing folk, their job is to be gung-ho.
Start out with a scaleable development process; I'd recommend something like Scrum or eXtreme Programming. The point is that when it comes time to scale up the development team, you don't want to find out that the old ways of getting stuff done don't work anymore, and you have to invent a bunch of new processes at the same time as getting your new team members up to speed.
Start acting like a big company in other ways. Make sure you've thought about (and written down) the things that non-owners tend to care about - how you reward people, how you measure their contribution, what your standards are for performance and contribution.
Good luck with your endeavour. Oh, final piece of advice : Don't rely on/. for this kind of advice !
Sounds like your architecture is fundamentally broken. I don't think java is the cause of the brokenness; I'm guessing that if you implemented the same architecture in PHP/ASP/PERL/COBOL it would suck. I have personally been in this position - I managed a development team which had inherited a large piece of web architecture (not java !) from a consulting firm just prior to launch (yeah, I should have seen it coming), and it didn't scale. At all. On our big, expensive, 4-processor sun boxen, we could support a total of 12 concurrent interactive users. We were expecting a few million. DOH ! We had very little time, and looked at our options - we knew the architecture was fundamentally broken, we knew it would not support our business requirements, but we also had to go live in 3 months with 76 websites and millions of users. We decided to put in place a program of short, medium and long-term refactorings. The short-term stuff was all about shoring up the application for launch - we used Squid to cache the static content, we rewrote a bunch of key bottlenecks, and generally did heroic stuff. We did this through "SWAT Teams" - each team was responsible for one key performance area we had identified. They had a great amount of latitude, and very clear, measurable performance targets. The medium term improvements focused on improving the architecture to make it more flexible and extensible, so we could support our long-term objective : moving away from the architecture and re-building piece by piece in a new framework. On the whole, this worked very well - the sites survived their launch, and regularly serve a million or so pages a day. We migrated key areas to our new framework (which was based on Java, natch), and performance went away as a key business risk. After only a few months, the business changed direction and we couldn't afford to continue our re-architecture plans and had to concentrate on short-term feature improvements instead, but that was sorta okay - our refactorings had given us the opportunity to do that and not worry too much about performance.
So, my advice to you is to look at the architecture you have now, what you want to end up with, and draw a roadmap. Make sure the roadmap contains numerous delivery points, because you may have to stop what you were doing halfway through, but if you've delivered at least some of your improvements, you can reap their benefits immediately. Oh, and good luck.
(Transatlantic vocabulary warning : for "CV" you may read "resume".)
One of the insights I got recently is that recruitment (esp these days) is not about finding the absolute best person for the job. It's about the trade-off between the investment in finding that person and the eventual quality of the eventual hire, with a bottom line requirement of not hiring bozo the clown. If you post an ad on a jobs website (or in a newspaper or magazine or whatever), you're going to get inundated with candidates and have to invest a lot of time in filtering them. If you rely on word of mouth, you're going to get relatively few candidates and may not get the optimal number to choose from. If you use a headhunter, you should get to somewhere in between - a filtered selection of CVs to peruse. Is that worth 30% of the salary of the new hire ? That's up to you to decide. The quality of the filtering process largely determines the value the headhunter adds - any bozo can put an advert up and collect names and addresses of people who vaguely match the requirement. If you get too many false positives - people who are clearly not right for the position - or too few suitable candidates in your filtered list, you're not getting value. If you get a shortlist of 10 people, filtered out of the 2000 applicants who responded, and they are all brilliant matches, you're getting good value. In the boom days, a headhunter could claim to add value by their "network" of candidates who were otherwise not available - this usually translated to weasel techniques which people with ethics would not sink to - but it's not like there's a shortage of good techies just waiting for a decent job, these days.... Depending on how many people you're hiring, you could consider taking the function in-house. It's a simple calculation - x% times the expected salary times the number of candidates gives you a recruitment budget; if it exceeds the salary of a decent HR person, hire one. (Oh, wait, how do you recruit this HR person ? Through a headhunter ?). Whatever you do, don't make the mistake of believing that your headhunter guy has your interests at stake - they're running a business. Many recruitment firms incentivise their employees based on commision; this leads to the kind of excesses other posts have mentioned. As long as you know and understand that this is the case, you can get value out of them.
There's a fair amount of research to back this up.
on
The Bionic Office
·
· Score: 1
In one of Steve McConnell's books there's mention of research into developer productivity - the long & short of it is that offices with doors that close and enough space for 2 or more people to chat around a table appears to have a direct influence on programmer producitivity. Peopleware by Demarco & Lister contains a few chapters on the subject too; I seem to recall sample office layouts from some IBM hangar which was cited as a good example of office space for software developers.
I like the photos Joel posted, except for the fact there doesn't appear to be space for whiteboards and book cases.
The European head of MSN was on the news this morning; she was singing the praises of messenger, including the highly dubious claim that "MSN Messenger is safe, because you know who you are talking to, unlike a chatroom where you can just bump into anyone". Huh ? You know who you're talking to on Messenger ? All you know is some hotmail account name; there's absolutely no guarantee that "bobby13" is indeed a 13 year old and not some drooling psychopath.
because IT tends to over-promise and under-deliver. In addition, of course, IT teams tend to be better paid than most, and the stuff we do is hard to quantify - what's the value to the company of an email system ? a billing system ? a website ?
In "Dancing with bears", Tom Demarco and Tim Lister make the point that on an IT project, we're tracking costs to an ever-increasing degree - time, expenses, over-runs down to the cent - but almost never track the benefits. The feature that gets added to the project because the VP read about it in a magazine, the little switch that lets your favourite customer bypass the security system, the 87th report - they may well be hugely valuable, but we just don't know.
Efficiency is not just determined by cost, it's the ratio of cost to benefit. On the IT side, we can controll (some of) the costs, but surely it's up to the business to make sure that the benefit is managed equally professionally.
The lure of off-shore outsourcing is twofold - there's the promise of cheaper stuff, but also the reduced requirement of the business to justify the benefits of their projects and features. Instead of a partnership between the "business" and the IT team, the relationship becomes "customer/vendor", which for many business folk is a lot more comfortable.
In the long run, I believe that - unless you manage the benefits - there is no price point at which you can afford to ignore the benefit part of the equation.
Like a previous post, I'd suggest "evolving" to testability - every time you fix a bug or add a feature, do it test first. You will have to spend some time setting up the testing framework - a structure for your unit tests, the "non-code" stuff, and a way of finding out asap that you've broken a test. Depending on your environment, you could use something like AntHill or CruiseControl to automatically run all your unit tests as part of a (timed) build process, and email the results. CruiseControl also allows you to specify regular intervals at which your entire code-base is checked out of source code control, and unit-tested - you get an email if something breaks. A key problem for most systems is getting all the "non-code" stuff (in my case mostly databases etc.) into a known-good state so you can rely on a unit test reporting accurate errors when trying to insert a duplicate value or delete a non-existing record - again, automate using (something like) Ant - Ant will do a lot of this stuff for you on non-java projects too. Once you have refactored sufficiently, you can hopefully start testing independently from the "non-code" items. I'd suggest buying Kent Beck's book "Test Driven Development" for more ideas on how to code in this paradigm - it's very very good. Another book worth reading is The Pragmatic Programmer (they have a website too). Especially the "no broken windows" section is very worthwhile...
Slashdot Mirror
- Very, very insightful -
It is plainly wrong for companies to take our IP protection on overly broad terms, which are already in the public domain - but to then seek to enforce them is clearly even worse.
The writer of the Open Letter to Jeff Bezos knew what he was talking about.
In this article, Lawrence Lessig explains why broadband sucks in the US - but he draws almost the opposite conclusion to the author of this piece...."Let the markets, both private and public, compete to provide the service that telecom and cable has not."
Cryptonomicon was fantastic, the Baroque cycle is terrific - what's next?
I think you may be underestimating the skill and experience a good front-end designer brings to bear on a project. Imagine somone asking "I know how to code pretty HTML and I'm a photoshop wizard, but now I want to do a 2-week course and learn servlets and database programming so I can offer the whole package".
You can absolutely look at improving your skills as a designer - someone mentioned Nielsen, you might also want to read Alan Cooper's "The inmates are running the asylum", and Joel Spolsky's book on user interface design, and maybe grab a book on general graphic design basics (colours, typography, layout) - if you have a good eye and are meticulous, that should improve the general look of your work. Just don't expect to go on a 2 week course and become a UI whizz.
Now, I can code. I understood the problem domain, I have a lot of experience managing complex projects and 3rd party suppliers, and we knew pretty much what we wanted. It was still a nightmare.
Here's what I recommend
Now, a brief word about equity - you have to balance the value of your cash against your equity. If you retain 100% of the company but go bust in 6 months for lack of cash, your equity is effectively valueless. On the other hand, if you hand 95% of your equity to a blood-sucking VC and your company goes public at a value of $100 million, you will _feel_ like you lost 95 million dollars, and you will almost certainly lose control of the company.
Now, it is absolutely true that giving away too much equity too early is almost certainly going to mean you lose control of your company. But if you can find a bunch of decent programmers who are willing to work for a bit of cash and a reasonable equity stake, you have a decent chance of holding on to your cash for a while longer, getting some highly motivated business partners without losing the farm.
In case you're interested, we rewrote 80% of the original code within 6 months, the company's still alive but never really got the impetus we all hoped for, and I left after around 18 months.
And the TDD book by Kent Beck shows how the evolution of an application can be driven by unit tests.
Fwiw - I'd suggest that a large project is _not_ the best way to get to understand how unit testing works - there is likely to be way more detail than you need or want. Matt Raible shares some code (esp. AppFuse) which includes unit tests, and describes them in his wiki on Appfuse tutorials.
His "Struts Resume" demo application contains some pretty interesting unit tests of a real-world application.
Now, here's the skinny for me : using testing as an integral part of your development cycle helps you to separate the layers and components in your application. Every time you find yourself thinking "how am I going to test this - it's too difficult/intertwingled/dependent on other stuff", you have identified a design deficiency. Making the software easy to test will make it easy to understand, and easy to work with in future. By architecting the application to make it easy to test independently of the database, you make it resilient against changes in the underlying database technology, and - oh, yeah, you have some self-documenting code to show others how to call your api.
Good place to start reading is Robert Martin's "Agile Software Development".
I've been managing software development teams for around 7 years now. My initial promotion into management was scary - I was working on a politically highly sensitive project, using technology I'd never seen before, when the project manager left. He was one of the most respected managers in the organisation, and I was asked to take over the project - which was still at the very early stages.
I thought about many of the same questions posed in this post - I knew how bad the politics were likely to get, I didn't feel comfortable with the technology we were using, and I didn't think I'd get the corporate support to help me deliver.
But I took the challenge. Why ? Because I saw that delivering this seemingly impossible project would strengthen my position as a manager, because I believed in the team we'd created, and because I did my homework.
Homework is essential : I made sure I had a mentor. He was a senior manager elsewhere in the organisation who could help me work through managerial issues, and pull a few strings when I needed to bypass a political hurdle. I sat down with the team members and worked through our plan for the next 10 weeks and saw we could achieve our goals. The team members and I discussed what the change from "co-worker" to "boss" would mean for us all, and we were all fine with it. I discussed the project in detail with the person who would become my new boss, and made sure he had the wherewithall to back me up with a lot of the politics of the situation. I drank a lot of coffee with the other manager at that level to find out the realities of the situation, and then I made the jump.
It worked out for me - but I made sure I understood the situation well enough to believe the odds were in my favour. It took hard work, a lot of help from the team and my peer group, mentor and boss, but our project was an outstanding succes. I was rewarded with - guess what - new projects which were in way more trouble than that first one.
So, think about what it means to be a manager. As a manager, your value to the company is largely your ability to get other people to perform at the peak of their ability to fulfill goals that further the company's interests. That means your value is far greater if you rescue a failing project than if you take over a project that is already near-optimal and maybe eek out a couple of improvements.
You personally will learn far more from managing a project in trouble (as long as you have the organisational support that makes a succes possible) than from taking over a surefire winner. Take the opportunity to learn - but only if that is what you want, and if that is what you think you are good at.
Security is a process, not a product (no, I didn't make that up - check Bruce Schneier's company).
Security is a fairly wideranging topic, and involves at least half a dozen different, highly specialized disciplines. You may not need to be particularly thorough in all of them, but if you follow the great advice to use Nessus for network scanning, you may not realize that your client has left a gaping big hole in their ASP code which will allow arbitrary database requests to be executed against your client's database.
Or, you could have tightened down your network and website, but have no protection against viruses or worms on the desktop. Or there may be a wifi point allowing access to all and sundry. Or the server room may be accessible from the kitchen where many casual staff work. Or your client's CEO's daughter's boyfriend might have access to his PC with a VPN connection that automatically starts without prompting for a password....
So, yes, it's a good idea to use automated tools to do a basic audit. Nessus is good. You could do worse than read "Hacking Exposed" - it mentions a lot of good tools, both free and commercial, as well as the basic process for conducting a security audit.
However, make sure your client realizes that a clean bill of health (or fixing the issues your tools reported) does not mean they are "safe", (nor that they can sue you for any breaches that might occur), but rather that their organisation is not vulnerable to the attacks you tested for. If you didn't "test" hiring practices, they have no idea whether they are protected against employee fraud (which is still by far the most common form of computer crime). If you didn't "test" their virus protection policy, they have no idea of how exposed they are to the next email worm.
And of course, you are never "safe" - new threats emerge every day, and a server that was as safe as Fort Knox yesterday might be more like a crackhouse when the latest spl0it is released. So it's an ongoing process - assess, evaluate, repair, repeat & rinse.
Now, if your client is a small local firm with family members as employees, who use computers only for non-critical tasks, the "we'll run Nessus once a month" approach might be okay. If they are - oh, say, Microsoft...- that approach is clearly not sufficient.
Think about the interests of your client - not just in terms of saving them money, but protecting them from risk.
in fact, you should avoid any promotion opportunity which might require wit, determination, creativity and the ability to fix stuff or motivate people.
In your place, I'd hold out until they offer to mail you your pay check at home while you telecommute. It's a well-known fact that all managers are lazy and stupid, so why expect to get promoted for doing something even remotely resembling work ?
Oh, and another really helpful tip - use Startrek as the basis for making life decisions. No, really - it's sooooo realistic !
It all depends on what the course being taught is. If you are teaching computer science, I concur with the "read the writings of C.J.Date before touching a computer" post. If the course is "office automation tools" or somesuch(what is the school of communication, anyway ?), Access is certainly suitable - it's very accesible for non-techies.
For what it's worth, I think it's a mistake for a University to teach people who are likely to end up in a programming career using Access - any prospective employer will look at a CV containing Access and think "macro monkey", not "code guru". Check the job-sites - programming jobs usually require a server-scale RDBMS; secretarial and office support jobs require Access. When I hire for programming jobs, I usually assume knowledge of any of DB2, Sybase, Informix, Oracle, Postgres, MySQL, MS SQL Server will relatively easily transfer to our platform, but that someone who uses Access will be too bound to the query builder interface to get up to speed quickly.
on the BBC (radio 4, Midweek, 5 Nov 2003, I think) in which he told the interviewer he had an absolutely crucial scene in the final episode - he seemed to believe it was going to be in the film, I'm sure !
And abstraction is the fundamental means of reducing complexity.
The history of programming is the movement from physically inserting patch cables to program a computer to manipulating abstractions. In languages like C, those abstractions are still pretty close to the hardware; in OO languages they tend to be closer to the problem domain. Edsger Dijkstra once said that software development was unique as a profession because it required practitioners to operate at 7 levels of abstraction - from transistor to algorithm to software architecture to business domain. Of course, very few of us deal with "transistor-level" programming these days.
So, Simonyi's "intentional" programming is part of this broad sweep of improvement in programming languages in the last 50 or so years. The current emphasis behind Model-driven architecture is a similar desire to somehow take away all that messy code stuff and replace it with nice, easy to understand pictures.
The problem with both these approaches is that complexity exists inherently in the problem domain. The role of a software development team is to chose a path through that complex problem domain and implement it with working code. Right now, I don't believe we have tools which are sufficiently expressive and intuitive to model the complexity of the problem domain, and we must be years if not decades away from being able to convert such models to working code.
UML is lovely - it's a great language for expressing software ideas and conveying a lot of information in a graphical format, but the average business user just does not get it; in my experience they are primarily useful for communicating between developers.
Use cases (in textual form) are far more useful for communicating with business users, but to convert a usecase into a working program would require natural language parsing at a level that must be a generation away.
We should wish Simonyi luck - his ambitions are worthy, and will benefit all working developers if they bear fruit. And what better use to put a couple of billion dollars to ?
I used to be the development manager for a content-based website, and we had significant performance issues.
We had a limited budget, and buying even tens of thousands of dollars worth of licenses was - in our view - a bad use of that budget. Instead, we concentrated on building a test infrastructure with known performance characteristics, and extrapolated (sorry, I meant "guessed") that this performance profile would scale by a factor of X on the live infrastructure. By using a relatively small and flexible test infrastructure, we could rapidly cycle through load test scenarios and find whether any particular change moved us in the right direction. We determined a set of key performance criteria for the test infrastructure, and found out quickly what the overall trend was because we could run several fullscale loadtest scenarios per day.
We used Loadrunner - but only using a limited number of concurrent users (100, I seem to recall), and since then I have used apache.org's JMeter product with similar levels of success.
As far as I know, if you absolutely have to be able to simulate thousands of concurrent users, the Mercury/Rational style commercial tools are the only ones available. I guess there are circumstances where this is appropriate - but the sheer effort of organising and running a test on that scale is a huge pain in the backside. If you can find a way to scale down your testing requirements - by running on lower spec infrastructure with optional throttling on key components - you reduce your licensing costs and improve the flexibility of your test process - if you can run several load tests a day without dimming the lights throughout the neighbourhood, load testing becomes "just another test", rather than a big deal.
The same question was asked in an
XP usenet post. In fact, in Kent Beck's book on eXtreme Programming, he discusses
the cost of changing software in the various stages of the development process,
and a recognition that this "10-100-1000" progression is not necessarily true is
a fundamental part of the XP philosophy.
For what it's worth, I believe there are many domains where that cost escalator
does not apply. If you have a well-designed application rolled out to a manageable
userbase with access to a helpdesk or the development team, it is fairly cheap to
release software, and it is cheap to find and fix bugs. It's reasonably cheap to
find and fix bugs on web projects, too.
There are also domains where fixing bugs after the release is extremely expensive -
embedded devices, shrinkwrapped software, software subject to regulatory checks.
At the time the metrics were collected, compile times were a significant issue for
pretty much all developers - the "code-compile-test" cycle could be hours or days.
Nowadays, most of us can compile our application in seconds or minutes (no, not
the linux kernel. Yet.) IDE's and case tools have made it easier to understand code,
and we have debuggers which allow us to look deep inside the application in real-time.
I don't think the "one-size-fits-all" metric was ever valid, just as there
is no "one-size-fits-all" development process. I think the ratio for any given project
has gone down from its level in the early 1980s, though.
I've used it and basically had a quiet rebellion on my hands in the software development team.
I strongly recommend that you look at how you are currently using MS Project - I love using it to plan projects, but I hate using it to track projects. If you are tracking the project using Excel (which you appear to be hinting at), you may find that a plan which is detailed enough to get your project off the ground is totally unsuitable for people to submit time-cards against (was I working on the fooble component or the integration of the greeble ? I spent half a day longer on the fooble than the project plan says, but my greebling went a lot faster - aargh ! I can't book more than the allocated hours ! Aaargh - I'll ask my manager to extend the number of hours for my foobling - manager loses will to live).
I quite like xplanner - it's designed to work with eXtreme Programming rather than "traditional" project management methodologies. For "enterprise" class, I'd suggest the Rational toolsuite....
before looking for software.
The software solution you need depends on the process you want to implement. For instance, do you just want any bozo to be able to assign work to you "because Bob said you were the person who does this kinda thing" ? Or do you want your PHB to have power of life and death over your to-do list ? Do you really want to tell the chief executive to use some web-based system to get his requests acknowledged ? Do you really want to mix major projects in with requests for a new network cable ?
The reason you are finding it difficult to find the software you are looking for is because none of the packages can address all your concerns. So, do what you would (presumably) do for any software project - get a couple of stakeholders together (from the business as well as IT), work out what you want, and then see how to address the need. If you start off with "from now on, we will use SuperRequestTracker Pro and all you plebs must learn it's intuitive interface to get your stuff done", you're pretty much doomed.
This is the shop you always wished you could visit as a kid - it's full of telescopes, microscopes, globes, sextants, apothecary bottles - the only thing missing is a stuffed crocodile hanging from the ceiling. They provided some of the props for Prof. Dumbledore's study in the latest Harry Potter film, and I personally believe that you can't get geekier than
A 19th century Zograscope, on an attractively turned mahogany column. We are tempted to say that the device was invented by King Zog of Albania in 1928, but it wasn't: it was first produced in 18th century France as an optical aid for viewing prints of landscapes. Overall height 60cm, nearly 24".
I mean, who wouldn't want a zograscope ? And only GBP950.00 !
I want to know that I can pay you $2K to build me a furtzwangler, and get $3K's worth of value out of it. I don't want to hear about how your PC needed to be reformatted (in my time), or how you looked at a cool new solution to a particular design problem (in my time) or how you had to rearchitect your OO persistence layer using the gesundheit design pattern.
It comes down to risk : software development is inherently unpredictable. Someone is going to have to take a risk - will the features I asked for take 6 weeks, 6 months, or 6 years ? You are in a far better position to estimate the duration of the project than I am, so it's only fair that you bear the risk.
Of course, that assumes that I am not a psychopath who changes the requirements every week and "forgets" to tell you it also has to run on the Amiga platform. That is the risk you bear - you might be able to build the required features in 6 months, but not if I keep changing my mind....
So here's what _can_ work as long as there is an amount of trust between you and the company who want to pay you.
This allows you to reduce your risk by not allowing the client to change their mind once you've agreed your current iteration's scope. As the scope of an iteration is likely to be relatively small, your client does not have to make a big, irrevocable decision about what they want exactly so you can do a big complicated estimate. The risk is effectively shared.
By seeing how much you get done in your iterations, you get a way to adjust your prices in a way that reflects reality - if it turns out you had to work day and night to complete your iteration, you need to charge more (or reduce the scope of what you take on in an iteration). If you have time to spare, you can take on more in the next iteration.
From personal experience :
Good luck with your endeavour.
Oh, final piece of advice : Don't rely on
Sounds like your architecture is fundamentally broken. I don't think java is the cause of the brokenness; I'm guessing that if you implemented the same architecture in PHP/ASP/PERL/COBOL it would suck.
I have personally been in this position - I managed a development team which had inherited a large piece of web architecture (not java !) from a consulting firm just prior to launch (yeah, I should have seen it coming), and it didn't scale. At all. On our big, expensive, 4-processor sun boxen, we could support a total of 12 concurrent interactive users. We were expecting a few million. DOH !
We had very little time, and looked at our options - we knew the architecture was fundamentally broken, we knew it would not support our business requirements, but we also had to go live in 3 months with 76 websites and millions of users.
We decided to put in place a program of short, medium and long-term refactorings. The short-term stuff was all about shoring up the application for launch - we used Squid to cache the static content, we rewrote a bunch of key bottlenecks, and generally did heroic stuff. We did this through "SWAT Teams" - each team was responsible for one key performance area we had identified. They had a great amount of latitude, and very clear, measurable performance targets.
The medium term improvements focused on improving the architecture to make it more flexible and extensible, so we could support our long-term objective : moving away from the architecture and re-building piece by piece in a new framework.
On the whole, this worked very well - the sites survived their launch, and regularly serve a million or so pages a day. We migrated key areas to our new framework (which was based on Java, natch), and performance went away as a key business risk. After only a few months, the business changed direction and we couldn't afford to continue our re-architecture plans and had to concentrate on short-term feature improvements instead, but that was sorta okay - our refactorings had given us the opportunity to do that and not worry too much about performance.
So, my advice to you is to look at the architecture you have now, what you want to end up with, and draw a roadmap. Make sure the roadmap contains numerous delivery points, because you may have to stop what you were doing halfway through, but if you've delivered at least some of your improvements, you can reap their benefits immediately.
Oh, and good luck.
(Transatlantic vocabulary warning : for "CV" you may read "resume".)
One of the insights I got recently is that recruitment (esp these days) is not about finding the absolute best person for the job. It's about the trade-off between the investment in finding that person and the eventual quality of the eventual hire, with a bottom line requirement of not hiring bozo the clown.
If you post an ad on a jobs website (or in a newspaper or magazine or whatever), you're going to get inundated with candidates and have to invest a lot of time in filtering them. If you rely on word of mouth, you're going to get relatively few candidates and may not get the optimal number to choose from. If you use a headhunter, you should get to somewhere in between - a filtered selection of CVs to peruse. Is that worth 30% of the salary of the new hire ? That's up to you to decide.
The quality of the filtering process largely determines the value the headhunter adds - any bozo can put an advert up and collect names and addresses of people who vaguely match the requirement. If you get too many false positives - people who are clearly not right for the position - or too few suitable candidates in your filtered list, you're not getting value. If you get a shortlist of 10 people, filtered out of the 2000 applicants who responded, and they are all brilliant matches, you're getting good value.
In the boom days, a headhunter could claim to add value by their "network" of candidates who were otherwise not available - this usually translated to weasel techniques which people with ethics would not sink to - but it's not like there's a shortage of good techies just waiting for a decent job, these days....
Depending on how many people you're hiring, you could consider taking the function in-house. It's a simple calculation - x% times the expected salary times the number of candidates gives you a recruitment budget; if it exceeds the salary of a decent HR person, hire one. (Oh, wait, how do you recruit this HR person ? Through a headhunter ?).
Whatever you do, don't make the mistake of believing that your headhunter guy has your interests at stake - they're running a business. Many recruitment firms incentivise their employees based on commision; this leads to the kind of excesses other posts have mentioned. As long as you know and understand that this is the case, you can get value out of them.
In one of Steve McConnell's books there's mention of research into developer productivity - the long & short of it is that offices with doors that close and enough space for 2 or more people to chat around a table appears to have a direct influence on programmer producitivity. Peopleware by Demarco & Lister contains a few chapters on the subject too; I seem to recall sample office layouts from some IBM hangar which was cited as a good example of office space for software developers.
I like the photos Joel posted, except for the fact there doesn't appear to be space for whiteboards and book cases.
The European head of MSN was on the news this morning; she was singing the praises of messenger, including the highly dubious claim that "MSN Messenger is safe, because you know who you are talking to, unlike a chatroom where you can just bump into anyone". Huh ? You know who you're talking to on Messenger ? All you know is some hotmail account name; there's absolutely no guarantee that "bobby13" is indeed a 13 year old and not some drooling psychopath.
I guess AOL is happy though.
because IT tends to over-promise and under-deliver. In addition, of course, IT teams tend to be better paid than most, and the stuff we do is hard to quantify - what's the value to the company of an email system ? a billing system ? a website ?
In "Dancing with bears", Tom Demarco and Tim Lister make the point that on an IT project, we're tracking costs to an ever-increasing degree - time, expenses, over-runs down to the cent - but almost never track the benefits. The feature that gets added to the project because the VP read about it in a magazine, the little switch that lets your favourite customer bypass the security system, the 87th report - they may well be hugely valuable, but we just don't know.
Efficiency is not just determined by cost, it's the ratio of cost to benefit. On the IT side, we can controll (some of) the costs, but surely it's up to the business to make sure that the benefit is managed equally professionally.
The lure of off-shore outsourcing is twofold - there's the promise of cheaper stuff, but also the reduced requirement of the business to justify the benefits of their projects and features. Instead of a partnership between the "business" and the IT team, the relationship becomes "customer/vendor", which for many business folk is a lot more comfortable.
In the long run, I believe that - unless you manage the benefits - there is no price point at which you can afford to ignore the benefit part of the equation.
Like a previous post, I'd suggest "evolving" to testability - every time you fix a bug or add a feature, do it test first.
You will have to spend some time setting up the testing framework - a structure for your unit tests, the "non-code" stuff, and a way of finding out asap that you've broken a test.
Depending on your environment, you could use something like AntHill or CruiseControl to automatically run all your unit tests as part of a (timed) build process, and email the results. CruiseControl also allows you to specify regular intervals at which your entire code-base is checked out of source code control, and unit-tested - you get an email if something breaks.
A key problem for most systems is getting all the "non-code" stuff (in my case mostly databases etc.) into a known-good state so you can rely on a unit test reporting accurate errors when trying to insert a duplicate value or delete a non-existing record - again, automate using (something like) Ant - Ant will do a lot of this stuff for you on non-java projects too.
Once you have refactored sufficiently, you can hopefully start testing independently from the "non-code" items.
I'd suggest buying Kent Beck's book "Test Driven Development" for more ideas on how to code in this paradigm - it's very very good.
Another book worth reading is The Pragmatic Programmer (they have a website too). Especially the "no broken windows" section is very worthwhile...